On Wed January 20 2010, Peter Wang wrote:
> On 2010-01-19, Thomas Fjellstrom <tfjellstrom@...> wrote:
> > On Tue January 19 2010, Thomas Fjellstrom wrote:
> > > On Tue January 19 2010, Peter Wang wrote:
> > > > On 2010-01-19, Thomas Fjellstrom <tfjellstrom@...> wrote:
> > > > > > Another thing that's arguably as important as those, is a
> > > > > > "capabilities" framework, so people can query what they can,
> > > > > > and can't do on a given computer.
> > > >
> > > > Was there a proposal somewhere? What kind of capabilities did you
> > > > have in mind?
> > >
> > > I think there might have been a proper proposal, but at any rate its
> > > been mentioned on IRC and the list a few times in the past.
> > >
> > > What I think (and others seem to agree, SiegeLord, Elias, etc) is
> > > that there should be a list of common capabilities exported via an
> > > allegro API. So you can detect if there really is FAST hw
> > > acceleration (just having GL work is no indication), things like NPOT
> > > textures, FBO's, and other useful (but not always available) features
> > > should be advertised in a cross platform manner (yes, I'm aware "FBO"
> > > is a GL term, but D3D should have a corresponding feature).
> > >
> > > This way people can detect what features are available, and provide
> > > different code paths, before objects are even created.
>
> I would think that many of the graphical capabilities would not be known
> until OpenGL is initialised, which means you'd want to query it on a
> specific display. Maybe like:
>
> enum { ALLEGRO_CAPABILITY_NPOT_TEXTURES = 1, ... };
> bool al_get_display_capability(ALLEGRO_DISPLAY *dpy, int cap);
>
> Perhaps some capabilities are not boolean values, e.g. maximum texture
> size, so maybe we need multiple functions with different return types.
>
> > I'm not the one to work on the capabilities stuff, but I do have some
> > experience working with both Xinerama and XRandR, so I will volunteer
> > to work on that should no one else want to (as a last resort).
>
> As usual I can't find any documentation for Xrandr.h. Do you know where
> it is, or of a good example?
I basically just looked at KDEs code, and the header. I might have some
example code laying around some place, I wrote some for the display enum
code in a5, but it turns out it was (a lot) easier to just use Xinerama for
that. So the XRR code has been sitting. I've managed to find the code I
wrote, its quite the mess, and doesn't compile, seems I was in the middle of
reorganizing the code a bit when I stopped. But the XRandR code should be
clear enough. Also its XRR 1.2 code, it might not be entirely correct for
XRR 1.3+. I'll bet you can find a version that compiles fine if you look in
the archive, or on a.cc.
The major problem is nvidia STILL doesn't implement XRR 1.2 or better. And
Xorg in all their wisdom decided it was a good idea to fake the latest XRR
protocol version at the server level using whatever the gfx driver provides.
Which gives you bogus information on systems with the binary nvidia driver.
What you get out of xrandr on a system running the binary nvidia driver is a
single screen, regardless of how many actual screens you have, and it comes
with a bogus refresh rate (there /was/ a good reason for that at the time it
was implemented).
A proper implementation will have to check the number of Xinerama screens
against the number of screens XRR says you have, and if XRandR.num_screens <
Xinerama.num_screens, use XF86VidMode if you can.
> Peter
>
> -------------------------------------------------------------------------
> ----- Throughout its 18-year history, RSA Conference consistently
> attracts the world's best and brightest in the field, creating
> opportunities for Conference attendees to learn about information
> security's most important issues through interactions with peers,
> luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
>
--
Thomas Fjellstrom
tfjellstrom@...
|