> From: Adam Jackson <[email protected]> > Date: Thu, 08 Dec 2016 13:34:11 -0500 > > On Thu, 2016-12-08 at 09:19 -0800, Keith Packard wrote: > > > Adam Jackson <[email protected]> writes: > > > Assuming those bugs are gone, the only configurations that would break > > > are the two drivers mentioned in the commit message, and any manual > > > configuration that had set 24bpp in order to fit in available VRAM. > > > > At a minimum, forcing those to 16bpp would at least keep the screen lit > > up. > > It would, but xfree86 isn't set up to do that. The driver tells xfree86 > which depth/bpp it will use, then validates modes. Worse, the check > about whether to fail because there are no modes is in the driver, so > the best the server could do is notice that PreInit failed and retry at > 16bpp, which seems... icky. > > > > first two we can easily fix in code, the second is a little rougher. > > > Personally, given how antique 24bpp-supporting hardware is at this > > > point, I'm okay with just a release note saying that some > > > configurations might break. > > > > I thought there were a pile of 24bpp chips in recent server boxes? > > Said devices have KMS drivers so modesetting gets this right already. > Though the "antique" comment still kind of applies, the G200 core is > old enough to vote, and the emulated cirrus in qemu is at least two > years older than that.
The KMS drivers in question are unfortunately GPL'ed, which for some non-Linux OSes is a bit of an issue. It is also unfortunate that this means you won't be able to run X directly on the framebuffer set up by UEFI firmware on such servers and virtually all virtualization solutions. Not something I care very deeply about (I think interacting with a server through a serial port is far superior). But oters may beg to differ. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
