Debian debates systemd

Posted Jul 28, 2011 23:46 UTC (Thu) by mjg59 (subscriber, #23239)
In reply to: Debian debates systemd by dlang
Parent article: Debian debates systemd

Really? You can point at the userspace modesetting code for Sandybridge hardware?

Debian debates systemd

Posted Jul 28, 2011 23:55 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

My understanding is that Sandybridge support is still problematic for any use.

but even if there isn't ever userspace modesetting code for it, there are differences

1. the X team isn't going to reject paches that are submitted to add userspace modesetting code on the basis that they only care about Linux.

2. it's very common for _NEW_ hardware to not be supported under different operating systems, I see a huge difference between making it so that new software cannot run on existing systems and not supporting new hardware.

Debian debates systemd

Posted Jul 29, 2011 6:06 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (1 responses)

The last chipset to be added to the UMS path in the intel driver was GM45. Backported Iron Lake code exists but hasn't been merged, and nobody's shown any interest in Sandy Bridge. Meanwhile, nouveau no longer really supports UMS (including for chips it used to support) and modern Radeon is heading in that direction as well.

Would the X team reject patches that added UMS code to drivers that only have KMS drivers? I suspect so. It's additional complexity for almost no benefit. The people working on this code simply aren't interested in supporting BSDs if there's no commensurate effort on behalf of the BSD developers to implement compatible interfaces. The simple and observable fact is that X developers have little interest in supporting a fallback for non-Linux support on any vaguely modern hardware. BSD can catch up or BSD can run with VESA until the adoption of EFI makes that impossible.

Debian debates systemd

Posted Nov 5, 2013 21:38 UTC (Tue) by juliank (guest, #45896) [Link]

(Free)BSD caught up, AFAIK.