Debian debates systemd

Posted Jul 28, 2011 22:12 UTC (Thu) by dlang (guest, #313)
In reply to: Debian debates systemd by vonbrand
Parent article: Debian debates systemd

> BTW, I don't remember a similar tornado-in-a-teapot when X moved some stuff into the kernel...

that's because X did things right.

they take advantage of the new linux-only features if they exist, but they have a fallback that they use if those features don't exist.

the opposition you are seeing isn't "don't take advantage of Linux-only features" it's "don't be dependant on Linux-only features"

it doesn't even need to be that _everything_ still works without the Linux-only features available, but if a feature isn't available, the only thing that should not work are the particulars involving that feature, everything else should still work.

Debian debates systemd

Posted Jul 28, 2011 23:46 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (3 responses)

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.