On Sat, Feb 07, 2015 at 05:05:03PM +0100, Thomas Niederprüm wrote: > Am Sat, 7 Feb 2015 12:20:43 +0100 > schrieb Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>: > > > On Fri, Feb 06, 2015 at 11:28:11PM +0100, niederp@xxxxxxxxxxxxxxxx > > wrote: > > > From: Thomas Niederprüm <niederp@xxxxxxxxxxxxxxxx> > > > > > > This patch adds a module parameter 'bitsperpixel' to adjust the > > > colordepth of the framebuffer. All values >1 will result in memory > > > map of the requested color depth. However only the MSB of each > > > pixel will be sent to the device. The framebuffer identifies itself > > > as a grayscale display with the specified depth. > > > > I'm not sure this is the right thing to do. > > > > The bits per pixel for this display is rightfully defined, used and > > reported to the userspace, why would you want to change that? > > You are right of course. The display is 1bpp and it reports to be 1 > bpp. The problem is that there is almost no userspace library that can > handle 1 bit framebuffers correctly. So it is nice if the framebuffer > (optionally) can expose itself as 8 bits per pixel grayscale to the > userspace program. As an example this allows to run DirectFB on the > framebuffer, which is not possible out of the box for 1bpp. > > Also note that if do not set the module parameter at load time > the framebuffer will be 1bpp. So you have to actively set that module > parameter to make the framebuffer pretend to be more than 1bpp. > > In any case I don't cling to that patch, I just thought it was a nice > feature. I'd say that the right fix would be to patch DirectFB, instead of faking that in the kernel. But again, that's probably Tomi's call, not mine. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
