[lsb-discuss] X11 Extensions for Fullscreen OpenGL

Jan Emoti emotican at gmail.com
Mon Apr 28 10:09:09 PDT 2008

On Thu, Apr 24, 2008 at 11:34 AM, Jeff Licquia <jeff at licquia.org> wrote:

> Jan Emoti wrote:
> > Are there other alternatives to using randr, since they say it only
> > works with "recent versions of Linux" and there are "still have very serious
> > issues" for some hardware?
> >
> > Given that randr omits all Radeon R100 series AND GeForce 1-7 series
> > parts, would the loss of this massive installed-base discourage ISV's from
> > linux?
> >
> > Is libXxf86vm not in lsb because it was once not included in Debian
> > 3.1r2 on x86?
> >
> > If this is not the best list for these kind of questions please tell me
> > where to go.
> >
> It's no problem to discuss here; the answers you get, though, might be
> different than elsewhere.
> It seems to me that RandR is the future; it seems to work a lot better
> than its predecessors, and everyone who needs to do this seems to be moving
> to it.  Given that, it doesn't make sense for the LSB to adopt something
> that's going away.  If we were to adopt something, it would be RandR.

Is there any example code out there that uses RandR to achieve fullscreen?

> Very few X extensions are in the LSB.  I believe that, prior to LSB 3.2,
> none were.  The priorities for now are on things like Xtest, which are used
> by far more apps.

Would guess fullscreen tests are not possible since xtest is used to "test
the X11 server with no user intervention."

> It is a shame that some older hardware is getting left behind.  OTOH, this
> illustrates yet again why open-source drivers are important: you aren't left
> begging from your vendor or buying a new video card to support the newest
> stuff.  RandR isn't alone in this.

Reverse-compatibility should be just as important as forward-compatibility.
It increases the range of the linux desktop, without neglecting that which
has been tested by time. How likely is it that RandR would eventually
include elderly hardware? No one has the incentive to go back port, so the
potential user base for linux shrinks significantly.

> As a fix for your problem, you could use dlopen to conditionally use
> Xxf86vm or RandR, depending on what's supported.  This could even be done in
> an LSB-compliant manner, as long as the app had a fallback for when neither
> library is available.

Sounds better than leaving orphaned code behind. I wonder if lsbappchk would
still see libXxf86vm.so an impediment?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20080428/51b5f5e2/attachment.htm 

More information about the lsb-discuss mailing list