LWN.net Logo

ELC/LFCS2009: A tale of two panels

ELC/LFCS2009: A tale of two panels

Posted Apr 16, 2009 15:27 UTC (Thu) by bronson (subscriber, #4806)
Parent article: ELC/LFCS2009: A tale of two panels

> which Packard described as "open /dev/mem"

Good gravy. Yes, backwards compatibility is important but this interface sounds like an aberration. (I realize Packard is probably exaggerating a little...)

Would it be possible to have a well-planned step change?

1. make the new interface and the removal of the old an experimental feature that's off by default. Ensure userspace works with both interfaces.
2. Continue like this for two or more releases while it stabilizes. (try to encourage distros to flip the switch early in their dev cycles and see if it sticks?)
3. On the planned day in the planned release cycle, flip the switch everywhere and remove the old interface.

Of course, this only works when there's a single userspace client of the interface, and assumes it's possible to write a userspace utility that can use both interfaces equally well. Luckily both apply here.

I just hate the idea of someone having to waste time rewriting and forward-porting kludgy interfaces that should go away anyway. Or that nasty interfaces would hold things up for years. (OTOH, X is well known for pinning itself into situations like this, it's nothing new!)


(Log in to post comments)

ELC/LFCS2009: A tale of two panels

Posted Apr 19, 2009 1:44 UTC (Sun) by jlokier (guest, #52227) [Link]

I'm not sure that X is the only userspace client of "/dev/mem". What about SVGAlib? :-)

Also it would be nice if kernel modesetting for X and DirectFB got along.

ELC/LFCS2009: A tale of two panels

Posted Apr 19, 2009 20:58 UTC (Sun) by oak (subscriber, #2786) [Link]

> I'm not sure that X is the only userspace client of "/dev/mem". What
about SVGAlib? :-)

The above mentioned GGI solved that issue over ten years ago and it seems
to be still available:
http://packages.debian.org/lenny/svgalib1-libggi2

Btw. I too had been patching my kernel with KGI when I was still using
mostly console and still compiling my own kernels. KGI patched kernel was
so much nicer to somebody who'd been spoiled by other Unix like operating
systems that provided graphical consoles as KGI was much faster, provided
higher resolutions, higher CRT update frequency etc. than the crappy x86
text-mode based Linux console...

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds