Comment 32 for bug 527369

Revision history for this message
Chase Douglas (chasedouglas) wrote :

Basically, there's no good solution to this bug for Lucid. There's no reasonable way to keep vga16fb from loading when a suitable hw framebuffer is available. There's a hacked solution, but due to the lack of locking that I can find in register_framebuffer (maybe there's locking above, but I can't be sure) I'm afraid to add code that would prevent vga16fb from loading if another framebuffer already exists. Adding locking would help, but that's too large of an addition to Lucid at this point.

In M, we hope to be done with vga16fb and just use efifb, which would hand off to nouveau/intel/radeon properly (unlike vga16fb). So this is really just an issue with Lucid.

IMHO, for Lucid we should try to teach lshw to be careful with framebuffers. Why does it need to open the framebuffer at all?