[PATCH xserver 0/5] Remove (most) 24bpp support

[Mark Kettenis]

> From: Adam Jackson <ajax at redhat.com>
> Date: Thu, 08 Dec 2016 13:34:11 -0500
> 
> On Thu, 2016-12-08 at 09:19 -0800, Keith Packard wrote:
> > > Adam Jackson <ajax at redhat.com> 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.