Please modify your OpenGL using games to use opengl-games-utils

[Hans de Goede]

Hi All,

In preperation for the Games Live DVD, I've created a small bash script which
resides in opengl-games-utils, which is meant to be used as a wrapper around
OpenGL games. If DRI is available this wrapper does nothing, if it isn't it
will show an error dialog, explaining about Free Software and 3D drivers and
then exit.

The idea here is that an error dialog is better then trying to click the quit
menu option while the mouse is jumping from the right edge of the screen to the
left edge (mouse navigation is anything but easy at 3 fps).

This is esp. important for the Games Live DVD, as there people will not have
those other <beep> drivers available.

I've already added usage of this wrapper to all my games that are in the
kickstart file for the Live DVD, and I will file bugs for this against a couple
of the most highprofile games also in the kickstart, in the mean time everyone
please check all your games for OpenGL usage and necessary add the wrapper.

Adding the wrapper is _really_ easy:

Add: "Requires: opengl-games-utils"
Add to %install:
"ln -s opengl-game-wrapper.sh $RPM_BUILD_ROOT%{_bindir}/%{name}-wrapper"
Add "%{_bindir}/%{name}-wrapper" to files
Change the .desktop file Exec entry from "%{name}" to "%{name}-wrapper"
Done!

This all assumes your main binary name == %{name}, otherwise adapt as necessary.

If you already have a wrapper script for one reason or the other, you can
incorperate the checkDriOk function directly into your wrapper, no need todo a
wrapper wrapper, see vegastrike's vegastrike-wrapper.sh CVS file as example.

Regards,

Hans

[Gérard Milmeister]

Post by Hans de Goede
This is esp. important for the Games Live DVD, as there people will not have
those other <beep> drivers available.

I wonder if it makes any sense to include OpenGL games in such a Games
Live DVD, that does not provide <beep> drivers.

[Debarshi 'Rishi' Ray]

Post by Gérard Milmeister
I wonder if it makes any sense to include OpenGL games in such a Games
Live DVD, that does not provide <beep> drivers.

Why not? OpenGL games run on GPUs for which one has free software
drivers. eg., Intel. Thus one can use such a LiveCD to check the
availability and quality of graphics drivers and hardware before
buying a new computer.

Cheers,
Debarshi

[Richi Plana]

Post by Debarshi 'Rishi' Ray

Post by Gérard Milmeister
I wonder if it makes any sense to include OpenGL games in such a Games
Live DVD, that does not provide <beep> drivers.

Why not? OpenGL games run on GPUs for which one has free software
drivers. eg., Intel. Thus one can use such a LiveCD to check the
availability and quality of graphics drivers and hardware before
buying a new computer.

One worry I have is that there are a lot of hardware out there with
(currently) unsupported video cards and, in this case, first impressions
matter. If someone new to Fedora or linux gives it a try and can't even
get a single OpenGL-accelerated game running, that could do more harm
than good.

Of course, there's really nothing we can do about it at this point, but
I was wondering if there was a better way to mitigate the problem (like
add instructions on the error dialog for getting the needed drivers in
as few steps as possible).

Otherwise you may as well call the release
3D-Games-For-Intel-and-other-open-source-friendly-hardware-vendors
Release.
--

Richi Plana

[Rahul Sundaram]

Post by Richi Plana
Of course, there's really nothing we can do about it at this point, but
I was wondering if there was a better way to mitigate the problem (like
add instructions on the error dialog for getting the needed drivers in
as few steps as possible).

The wrapper will atleast inform you why the drivers aren't available and
IMO we should be encouraging the use of Free software drivers especially
at this point since both Intel and more recently ATI have come up with
them leaving Nvidia as as the odd man out which hopefully Nouveau (which
we already include) covers at a later stage.

Post by Richi Plana
Otherwise you may as well call the release
3D-Games-For-Intel-and-other-open-source-friendly-hardware-vendors
Release.

Well essentially Fedora is strongly Free software oriented anyway.
Compared to the current experience this is a improvement.

Rahul

[Jeff Spaleta]

Post by Richi Plana
Of course, there's really nothing we can do about it at this point, but
I was wondering if there was a better way to mitigate the problem (like
add instructions on the error dialog for getting the needed drivers in
as few steps as possible).

1) This tool is meant to help people running the Games LiveCD... no
way to install more drivers while in live mode.

2) No.. as a project we will not be handing out explicit instructions
on how to install 3rd party binary video drivers via a client dialog.

Post by Richi Plana
Otherwise you may as well call the release
3D-Games-For-Intel-and-other-open-source-friendly-hardware-vendors
Release.

And that is the WHOLE point. This is what Fedora IS, as a project it
is focused completely and utterly on the open source software stack.
We aren't sugar coating it or hiding the fact that video driver
coverage is a problem, by slipping users proprietary pills. Video
driver coverage IS a problem, its a problem that needs to be stressed
and not covered over in a very shallow and vain attempt to boost our
distribution numbers by sneaking in addon drivers we don't support as
a project.

As the information being churned out of the AMD/ATI spec releases
start to get churned into open driver development, something like
opengl intensive livecd makes a lot of sense to me as a tool to help
users who care about open source to make better hardware purchasing
choices.

-jef"please tell me the wrapper script dialog is disablable so users
who want to play with 3 fps video can do so..even in a livecd
install"spaleta

[Hans de Goede]

Post by Jeff Spaleta
-jef"please tell me the wrapper script dialog is disablable so users
who want to play with 3 fps video can do so..even in a livecd
install"spaleta

Well, the live cd has a modifiable filesystem and I'm sure it will contain a
texteditor so yes the script can be disabled (by commenting out the check), or
users can start the game from the commandline starting foo instead of
foo-wrapper which the menu entry will start.

Hans "wonders if jef got my mail about londonlaw" de Goede

[Jeff Spaleta]

Post by Hans de Goede
Hans "wonders if jef got my mail about londonlaw" de Goede

Oh i probably got it... and missed it.

-jef"goes digging into gmail cache and muses to himself that Google
and its Advertising partners probably already know that I got the
email and finds it disappointing that they didn't tell me by giving
me text ads related to London street crime and bus tickets."spaleta

[Jeff Spaleta]

Post by Hans de Goede
Well, the live cd has a modifiable filesystem and I'm sure it will contain a
texteditor so yes the script can be disabled (by commenting out the check),

I was thinking more like a environment variable that the script can
check for. So that on a per-user basis this can be disabled quickly
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.

-jef

[Doncho N. Gunchev]

Post by Jeff Spaleta

Post by Hans de Goede
Well, the live cd has a modifiable filesystem and I'm sure it will contain a
texteditor so yes the script can be disabled (by commenting out the check),

I was thinking more like a environment variable that the script can
check for. So that on a per-user basis this can be disabled quickly
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.
-jef

Why not a checkbox - don't show this warning again? If checked - touch
a file (say ~/.no_video_warning) and don't bother the user again.

I think the user should be able to abort the game start, to start anyway
and to start anyway and never be bothered again.

[Ian Chapman]

Post by Doncho N. Gunchev

Post by Jeff Spaleta
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.

Why not a checkbox - don't show this warning again? If checked - touch
a file (say ~/.no_video_warning) and don't bother the user again.
I think the user should be able to abort the game start, to start anyway
and to start anyway and never be bothered again.

+1

To be fair I haven't see the script (yet) but that sounds a like a
sensible suggestion to me. The user should have the option of continuing
regardless, if they so choose, and not to be bothered again. This should
be as simple as possible and done graphically, ideally at launch time.

[dragoran]

Post by Ian Chapman

Post by Doncho N. Gunchev

Post by Jeff Spaleta
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.

Why not a checkbox - don't show this warning again? If checked - touch
a file (say ~/.no_video_warning) and don't bother the user again.
I think the user should be able to abort the game start, to start anyway
and to start anyway and never be bothered again.

+1
To be fair I haven't see the script (yet) but that sounds a like a
sensible suggestion to me. The user should have the option of continuing
regardless, if they so choose, and not to be bothered again. This should
be as simple as possible and done graphically, ideally at launch time.

another thing....
the text should be translateable imho...

[Hans de Goede]

Post by Ian Chapman

Post by Doncho N. Gunchev

Post by Jeff Spaleta
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.

Why not a checkbox - don't show this warning again? If checked - touch
a file (say ~/.no_video_warning) and don't bother the user again.
I think the user should be able to abort the game start, to start anyway
and to start anyway and never be bothered again.

+1
To be fair I haven't see the script (yet) but that sounds a like a
sensible suggestion to me. The user should have the option of continuing
regardless, if they so choose, and not to be bothered again. This should
be as simple as possible and done graphically, ideally at launch time.

There are 2 issues with these train of thoughts:
1) There really is no reason to want to run fullscreen OpenGL programs without
hardware acceleration, they will not be usable <period>. If you don't
believe me, try it!
2) The current wrapper uses zenity, so it cannot do the advenced kind of
dialogs with a checkbox people ask for.

All in all I believe less is more, so that things are fine as is, the menu
entries all launch foo-wrapper, if a user _really_ think he / she knows better,
all she needs todo is to launch foo, or to modify the menu entry and strip the
wrapper.

Regards,

Hans

[Doncho N. Gunchev]

Post by Hans de Goede

Post by Ian Chapman

Post by Doncho N. Gunchev

Post by Jeff Spaleta
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.

Why not a checkbox - don't show this warning again? If checked - touch
a file (say ~/.no_video_warning) and don't bother the user again.
I think the user should be able to abort the game start, to start anyway
and to start anyway and never be bothered again.

+1
To be fair I haven't see the script (yet) but that sounds a like a
sensible suggestion to me. The user should have the option of continuing
regardless, if they so choose, and not to be bothered again. This should
be as simple as possible and done graphically, ideally at launch time.

1) There really is no reason to want to run fullscreen OpenGL programs without
hardware acceleration, they will not be usable <period>. If you don't
believe me, try it!

I know, from a long time. Users *should* be able to see it with their own eyes.

Post by Hans de Goede
2) The current wrapper uses zenity, so it cannot do the advenced kind of
dialogs with a checkbox people ask for.

Well... improvise:

ans=$(zenity --list --text "Your video..." --radiolist --column "Pick" \
--column "Option" FALSE "Run" TRUE "Don't run" FALSE "Never run such programs" \
FALSE "Always run regardless"); echo $ans

Doesn't this look OK?

Post by Hans de Goede
All in all I believe less is more, so that things are fine as is, the menu
entries all launch foo-wrapper, if a user _really_ think he / she knows better,
all she needs todo is to launch foo, or to modify the menu entry and strip the
wrapper.

I wish you were correct, but most users have no idea they can edit their menu,
let alone what wrapper is. If I do such wrapper, will you get it in fedora?
I can also make it open terminal and use text mode dialog if zenity is not
installed or even fallback to plain text questions. The translation should be
no problem too (echo $"Translatable text" AFAIK)[1].

[1] - http://tiswww.case.edu/php/chet/bash/bashref.html#SEC13

[Hans de Goede]

Post by Doncho N. Gunchev

Post by Hans de Goede

Post by Ian Chapman

Post by Doncho N. Gunchev

Post by Jeff Spaleta
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.

Why not a checkbox - don't show this warning again? If checked - touch
a file (say ~/.no_video_warning) and don't bother the user again.
I think the user should be able to abort the game start, to start anyway
and to start anyway and never be bothered again.

+1
To be fair I haven't see the script (yet) but that sounds a like a
sensible suggestion to me. The user should have the option of continuing
regardless, if they so choose, and not to be bothered again. This should
be as simple as possible and done graphically, ideally at launch time.

1) There really is no reason to want to run fullscreen OpenGL programs without
hardware acceleration, they will not be usable <period>. If you don't
believe me, try it!

I know, from a long time. Users *should* be able to see it with their own eyes.

Post by Hans de Goede
2) The current wrapper uses zenity, so it cannot do the advenced kind of
dialogs with a checkbox people ask for.

ans=$(zenity --list --text "Your video..." --radiolist --column "Pick" \
--column "Option" FALSE "Run" TRUE "Don't run" FALSE "Never run such programs" \
FALSE "Always run regardless"); echo $ans

I don't think we want the "Never run such programs" option, as from then on
such programs would silently fail. But other then that it might be ok. I would
need to see it. If someone wants to spend some time on implementing this and it
doesn't look horrible I would be more then happy to take a patch for this.

Please submit any patches through bugzilla.

Regards,

Hans

[Doncho N. Gunchev]

Post by Hans de Goede

Post by Doncho N. Gunchev

Post by Jeff Spaleta
for all games just by exporting the environment variable. Since you

...

Post by Hans de Goede

Post by Doncho N. Gunchev
ans=$(zenity --list --text "Your video..." --radiolist --column "Pick" \
--column "Option" FALSE "Run" TRUE "Don't run" FALSE "Never run such programs" \
FALSE "Always run regardless"); echo $ans

I don't think we want the "Never run such programs" option, as from then on
such programs would silently fail. But other then that it might be ok. I would
need to see it. If someone wants to spend some time on implementing this and it
doesn't look horrible I would be more then happy to take a patch for this.
Please submit any patches through bugzilla.

Hm, this means against opengl-games-utils, which I just discovered I have
installed. The "Never run such programs" was just an example. I'll see
what I can do :-)

[Doncho N. Gunchev]

Post by Hans de Goede

Post by Doncho N. Gunchev

Post by Jeff Spaleta
for all games just by exporting the environment variable. Since you

...

Post by Hans de Goede

Post by Doncho N. Gunchev
ans=$(zenity --list --text "Your video..." --radiolist --column "Pick" \
--column "Option" FALSE "Run" TRUE "Don't run" FALSE "Never run such programs" \
FALSE "Always run regardless"); echo $ans

I don't think we want the "Never run such programs" option, as from then on
such programs would silently fail. But other then that it might be ok. I would
need to see it. If someone wants to spend some time on implementing this and it
doesn't look horrible I would be more then happy to take a patch for this.
Please submit any patches through bugzilla.

Hm, this means against opengl-games-utils, which I just discovered I have
installed. The "Never run such programs" was just an example. I'll see
what I can do :-)

[Hans de Goede]

Post by Doncho N. Gunchev

Post by Hans de Goede

Post by Ian Chapman

Post by Doncho N. Gunchev

Post by Jeff Spaleta
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.

Why not a checkbox - don't show this warning again? If checked - touch
a file (say ~/.no_video_warning) and don't bother the user again.
I think the user should be able to abort the game start, to start anyway
and to start anyway and never be bothered again.

+1
To be fair I haven't see the script (yet) but that sounds a like a
sensible suggestion to me. The user should have the option of continuing
regardless, if they so choose, and not to be bothered again. This should
be as simple as possible and done graphically, ideally at launch time.

1) There really is no reason to want to run fullscreen OpenGL programs without
hardware acceleration, they will not be usable <period>. If you don't
believe me, try it!

I know, from a long time. Users *should* be able to see it with their own eyes.

Post by Hans de Goede
2) The current wrapper uses zenity, so it cannot do the advenced kind of
dialogs with a checkbox people ask for.

ans=$(zenity --list --text "Your video..." --radiolist --column "Pick" \
--column "Option" FALSE "Run" TRUE "Don't run" FALSE "Never run such programs" \
FALSE "Always run regardless"); echo $ans

I don't think we want the "Never run such programs" option, as from then on
such programs would silently fail. But other then that it might be ok. I would
need to see it. If someone wants to spend some time on implementing this and it
doesn't look horrible I would be more then happy to take a patch for this.

Please submit any patches through bugzilla.

Regards,

Hans

[Doncho N. Gunchev]

Post by Hans de Goede

Post by Ian Chapman

Post by Doncho N. Gunchev

Post by Jeff Spaleta
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.

Why not a checkbox - don't show this warning again? If checked - touch
a file (say ~/.no_video_warning) and don't bother the user again.
I think the user should be able to abort the game start, to start anyway
and to start anyway and never be bothered again.

+1
To be fair I haven't see the script (yet) but that sounds a like a
sensible suggestion to me. The user should have the option of continuing
regardless, if they so choose, and not to be bothered again. This should
be as simple as possible and done graphically, ideally at launch time.

1) There really is no reason to want to run fullscreen OpenGL programs without
hardware acceleration, they will not be usable <period>. If you don't
believe me, try it!

I know, from a long time. Users *should* be able to see it with their own eyes.

Post by Hans de Goede
2) The current wrapper uses zenity, so it cannot do the advenced kind of
dialogs with a checkbox people ask for.

Well... improvise:

ans=$(zenity --list --text "Your video..." --radiolist --column "Pick" \
--column "Option" FALSE "Run" TRUE "Don't run" FALSE "Never run such programs" \
FALSE "Always run regardless"); echo $ans

Doesn't this look OK?

Post by Hans de Goede
All in all I believe less is more, so that things are fine as is, the menu
entries all launch foo-wrapper, if a user _really_ think he / she knows better,
all she needs todo is to launch foo, or to modify the menu entry and strip the
wrapper.

I wish you were correct, but most users have no idea they can edit their menu,
let alone what wrapper is. If I do such wrapper, will you get it in fedora?
I can also make it open terminal and use text mode dialog if zenity is not
installed or even fallback to plain text questions. The translation should be
no problem too (echo $"Translatable text" AFAIK)[1].

[1] - http://tiswww.case.edu/php/chet/bash/bashref.html#SEC13

[dragoran]

Post by Ian Chapman

Post by Doncho N. Gunchev

Post by Jeff Spaleta
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.

Why not a checkbox - don't show this warning again? If checked - touch
a file (say ~/.no_video_warning) and don't bother the user again.
I think the user should be able to abort the game start, to start anyway
and to start anyway and never be bothered again.

+1
To be fair I haven't see the script (yet) but that sounds a like a
sensible suggestion to me. The user should have the option of continuing
regardless, if they so choose, and not to be bothered again. This should
be as simple as possible and done graphically, ideally at launch time.

another thing....
the text should be translateable imho...

[Hans de Goede]

Post by Ian Chapman

Post by Doncho N. Gunchev

Post by Jeff Spaleta
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.

Why not a checkbox - don't show this warning again? If checked - touch
a file (say ~/.no_video_warning) and don't bother the user again.
I think the user should be able to abort the game start, to start anyway
and to start anyway and never be bothered again.

+1
To be fair I haven't see the script (yet) but that sounds a like a
sensible suggestion to me. The user should have the option of continuing
regardless, if they so choose, and not to be bothered again. This should
be as simple as possible and done graphically, ideally at launch time.

There are 2 issues with these train of thoughts:
1) There really is no reason to want to run fullscreen OpenGL programs without
hardware acceleration, they will not be usable <period>. If you don't
believe me, try it!
2) The current wrapper uses zenity, so it cannot do the advenced kind of
dialogs with a checkbox people ask for.

All in all I believe less is more, so that things are fine as is, the menu
entries all launch foo-wrapper, if a user _really_ think he / she knows better,
all she needs todo is to launch foo, or to modify the menu entry and strip the
wrapper.

Regards,

Hans

[Ian Chapman]

Post by Doncho N. Gunchev

Post by Jeff Spaleta
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.

Why not a checkbox - don't show this warning again? If checked - touch
a file (say ~/.no_video_warning) and don't bother the user again.
I think the user should be able to abort the game start, to start anyway
and to start anyway and never be bothered again.

+1

To be fair I haven't see the script (yet) but that sounds a like a
sensible suggestion to me. The user should have the option of continuing
regardless, if they so choose, and not to be bothered again. This should
be as simple as possible and done graphically, ideally at launch time.

[Doncho N. Gunchev]

Post by Jeff Spaleta

Post by Hans de Goede
Well, the live cd has a modifiable filesystem and I'm sure it will contain a
texteditor so yes the script can be disabled (by commenting out the check),

I was thinking more like a environment variable that the script can
check for. So that on a per-user basis this can be disabled quickly
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.
-jef

Why not a checkbox - don't show this warning again? If checked - touch
a file (say ~/.no_video_warning) and don't bother the user again.

I think the user should be able to abort the game start, to start anyway
and to start anyway and never be bothered again.

[Jeff Spaleta]

Post by Hans de Goede
Hans "wonders if jef got my mail about londonlaw" de Goede

Oh i probably got it... and missed it.

-jef"goes digging into gmail cache and muses to himself that Google
and its Advertising partners probably already know that I got the
email and finds it disappointing that they didn't tell me by giving
me text ads related to London street crime and bus tickets."spaleta

[Jeff Spaleta]

Post by Hans de Goede
Well, the live cd has a modifiable filesystem and I'm sure it will contain a
texteditor so yes the script can be disabled (by commenting out the check),

I was thinking more like a environment variable that the script can
check for. So that on a per-user basis this can be disabled quickly
for all games just by exporting the environment variable. Since you
are asking for the games packages to use this by default, there needs
to be a per-user way to disable the script action on multi-user
configurations.

-jef

[Hans de Goede]

Post by Jeff Spaleta
-jef"please tell me the wrapper script dialog is disablable so users
who want to play with 3 fps video can do so..even in a livecd
install"spaleta

Well, the live cd has a modifiable filesystem and I'm sure it will contain a
texteditor so yes the script can be disabled (by commenting out the check), or
users can start the game from the commandline starting foo instead of
foo-wrapper which the menu entry will start.

Hans "wonders if jef got my mail about londonlaw" de Goede

[Rahul Sundaram]

Post by Richi Plana
Of course, there's really nothing we can do about it at this point, but
I was wondering if there was a better way to mitigate the problem (like
add instructions on the error dialog for getting the needed drivers in
as few steps as possible).

The wrapper will atleast inform you why the drivers aren't available and
IMO we should be encouraging the use of Free software drivers especially
at this point since both Intel and more recently ATI have come up with
them leaving Nvidia as as the odd man out which hopefully Nouveau (which
we already include) covers at a later stage.

Post by Richi Plana
Otherwise you may as well call the release
3D-Games-For-Intel-and-other-open-source-friendly-hardware-vendors
Release.

Well essentially Fedora is strongly Free software oriented anyway.
Compared to the current experience this is a improvement.

Rahul

[Jeff Spaleta]

Post by Richi Plana
Of course, there's really nothing we can do about it at this point, but
I was wondering if there was a better way to mitigate the problem (like
add instructions on the error dialog for getting the needed drivers in
as few steps as possible).

1) This tool is meant to help people running the Games LiveCD... no
way to install more drivers while in live mode.

2) No.. as a project we will not be handing out explicit instructions
on how to install 3rd party binary video drivers via a client dialog.

Post by Richi Plana
Otherwise you may as well call the release
3D-Games-For-Intel-and-other-open-source-friendly-hardware-vendors
Release.

And that is the WHOLE point. This is what Fedora IS, as a project it
is focused completely and utterly on the open source software stack.
We aren't sugar coating it or hiding the fact that video driver
coverage is a problem, by slipping users proprietary pills. Video
driver coverage IS a problem, its a problem that needs to be stressed
and not covered over in a very shallow and vain attempt to boost our
distribution numbers by sneaking in addon drivers we don't support as
a project.

As the information being churned out of the AMD/ATI spec releases
start to get churned into open driver development, something like
opengl intensive livecd makes a lot of sense to me as a tool to help
users who care about open source to make better hardware purchasing
choices.

-jef"please tell me the wrapper script dialog is disablable so users
who want to play with 3 fps video can do so..even in a livecd
install"spaleta

[Richi Plana]

Post by Debarshi 'Rishi' Ray

Post by Gérard Milmeister
I wonder if it makes any sense to include OpenGL games in such a Games
Live DVD, that does not provide <beep> drivers.

Why not? OpenGL games run on GPUs for which one has free software
drivers. eg., Intel. Thus one can use such a LiveCD to check the
availability and quality of graphics drivers and hardware before
buying a new computer.

One worry I have is that there are a lot of hardware out there with
(currently) unsupported video cards and, in this case, first impressions
matter. If someone new to Fedora or linux gives it a try and can't even
get a single OpenGL-accelerated game running, that could do more harm
than good.

Of course, there's really nothing we can do about it at this point, but
I was wondering if there was a better way to mitigate the problem (like
add instructions on the error dialog for getting the needed drivers in
as few steps as possible).

Otherwise you may as well call the release
3D-Games-For-Intel-and-other-open-source-friendly-hardware-vendors
Release.
--

Richi Plana

[Hans de Goede]

Post by Gérard Milmeister

Post by Hans de Goede
This is esp. important for the Games Live DVD, as there people will not have
those other <beep> drivers available.

I wonder if it makes any sense to include OpenGL games in such a Games
Live DVD, that does not provide <beep> drivers.

Yes it does, as OpenGL games will work fine on all integrated intel graphics
(lots of systems) and on all pre r5xx radeons (quite a few systems).

And who knows, with Fedora 9 we might have radeon 3d support over the whole
line, and nouveau 3d support for nvidea cards, and yes then we still want to
have this check, as there will always be some unsupported cards.

Regards,

Hans

[Nils Philippsen]

Post by Hans de Goede

Post by Gérard Milmeister

Post by Hans de Goede
This is esp. important for the Games Live DVD, as there people will not have
those other <beep> drivers available.

I wonder if it makes any sense to include OpenGL games in such a Games
Live DVD, that does not provide <beep> drivers.

Yes it does, as OpenGL games will work fine on all integrated intel graphics
(lots of systems) and on all pre r5xx radeons (quite a few systems).

Unfortunately not: https://bugzilla.redhat.com/show_bug.cgi?id=228414

Post by Hans de Goede
And who knows, with Fedora 9 we might have radeon 3d support over the whole
line, and nouveau 3d support for nvidea cards, and yes then we still want to
have this check, as there will always be some unsupported cards.

BTW: I've looked at the (F7) version of the script. Does it work with
AIGLX desktops? AFAICS, accelerated 3d should work there, but this is
indirect rendering and glxinfo should give "direct rendering: No". Then
there's the issue of proprietary 3D drivers completely bypassing the
DRI/DRM infrastructure.

Nils

[Hans de Goede]

Post by Nils Philippsen

Post by Hans de Goede

Post by Gérard Milmeister

Post by Hans de Goede
This is esp. important for the Games Live DVD, as there people will not have
those other <beep> drivers available.

I wonder if it makes any sense to include OpenGL games in such a Games
Live DVD, that does not provide <beep> drivers.

Yes it does, as OpenGL games will work fine on all integrated intel graphics
(lots of systems) and on all pre r5xx radeons (quite a few systems).

Unfortunately not: https://bugzilla.redhat.com/show_bug.cgi?id=228414

Excellent example of both why we need the wrapper, and why we want to have 3D
games on the games spin so people can check to see if things work in the store :)

Post by Nils Philippsen

Post by Hans de Goede
And who knows, with Fedora 9 we might have radeon 3d support over the whole
line, and nouveau 3d support for nvidea cards, and yes then we still want to
have this check, as there will always be some unsupported cards.

BTW: I've looked at the (F7) version of the script. Does it work with
AIGLX desktops? AFAICS, accelerated 3d should work there, but this is
indirect rendering and glxinfo should give "direct rendering: No". Then
there's the issue of proprietary 3D drivers completely bypassing the
DRI/DRM infrastructure.

I currently can't get 3D desktop effects to work on either my i386 i810, or my
x86_64 r300 machine. Is this a known problem? Could someone with working 3D
desktop effects please check to see if opengl-games-utils works properly or
not, and possibly come up with a patch to make it work in this scenario if
necessary?

Thanks & Regards,

Hans

[Wart]

Post by Hans de Goede

Post by Nils Philippsen

Post by Hans de Goede
And who knows, with Fedora 9 we might have radeon 3d support over the
whole line, and nouveau 3d support for nvidea cards, and yes then we
still want to have this check, as there will always be some
unsupported cards.

BTW: I've looked at the (F7) version of the script. Does it work with
AIGLX desktops? AFAICS, accelerated 3d should work there, but this is
indirect rendering and glxinfo should give "direct rendering: No". Then
there's the issue of proprietary 3D drivers completely bypassing the
DRI/DRM infrastructure.

I currently can't get 3D desktop effects to work on either my i386 i810,
or my x86_64 r300 machine. Is this a known problem? Could someone with
working 3D desktop effects please check to see if opengl-games-utils
works properly or not, and possibly come up with a patch to make it work
in this scenario if necessary?

On my F-7 x86_64 desktop with binary nvidia drivers and Desktop Effects
enabled (AIGLX), glxinfo still returns 'direct rendering: Yes'.

--Wart

[Wart]

Post by Hans de Goede

Post by Nils Philippsen

Post by Hans de Goede
And who knows, with Fedora 9 we might have radeon 3d support over the
whole line, and nouveau 3d support for nvidea cards, and yes then we
still want to have this check, as there will always be some
unsupported cards.

BTW: I've looked at the (F7) version of the script. Does it work with
AIGLX desktops? AFAICS, accelerated 3d should work there, but this is
indirect rendering and glxinfo should give "direct rendering: No". Then
there's the issue of proprietary 3D drivers completely bypassing the
DRI/DRM infrastructure.

I currently can't get 3D desktop effects to work on either my i386 i810,
or my x86_64 r300 machine. Is this a known problem? Could someone with
working 3D desktop effects please check to see if opengl-games-utils
works properly or not, and possibly come up with a patch to make it work
in this scenario if necessary?

On my F-7 x86_64 desktop with binary nvidia drivers and Desktop Effects
enabled (AIGLX), glxinfo still returns 'direct rendering: Yes'.

--Wart

[Hans de Goede]

Post by Nils Philippsen

Post by Hans de Goede

Post by Gérard Milmeister

Post by Hans de Goede
This is esp. important for the Games Live DVD, as there people will not have
those other <beep> drivers available.

I wonder if it makes any sense to include OpenGL games in such a Games
Live DVD, that does not provide <beep> drivers.

Yes it does, as OpenGL games will work fine on all integrated intel graphics
(lots of systems) and on all pre r5xx radeons (quite a few systems).

Unfortunately not: https://bugzilla.redhat.com/show_bug.cgi?id=228414

Excellent example of both why we need the wrapper, and why we want to have 3D
games on the games spin so people can check to see if things work in the store :)

Post by Nils Philippsen

Post by Hans de Goede
And who knows, with Fedora 9 we might have radeon 3d support over the whole
line, and nouveau 3d support for nvidea cards, and yes then we still want to
have this check, as there will always be some unsupported cards.

BTW: I've looked at the (F7) version of the script. Does it work with
AIGLX desktops? AFAICS, accelerated 3d should work there, but this is
indirect rendering and glxinfo should give "direct rendering: No". Then
there's the issue of proprietary 3D drivers completely bypassing the
DRI/DRM infrastructure.

I currently can't get 3D desktop effects to work on either my i386 i810, or my
x86_64 r300 machine. Is this a known problem? Could someone with working 3D
desktop effects please check to see if opengl-games-utils works properly or
not, and possibly come up with a patch to make it work in this scenario if
necessary?

Thanks & Regards,

Hans

[Nils Philippsen]

Post by Hans de Goede

Post by Gérard Milmeister

Post by Hans de Goede
This is esp. important for the Games Live DVD, as there people will not have
those other <beep> drivers available.

I wonder if it makes any sense to include OpenGL games in such a Games
Live DVD, that does not provide <beep> drivers.

Yes it does, as OpenGL games will work fine on all integrated intel graphics
(lots of systems) and on all pre r5xx radeons (quite a few systems).

Unfortunately not: https://bugzilla.redhat.com/show_bug.cgi?id=228414

Post by Hans de Goede
And who knows, with Fedora 9 we might have radeon 3d support over the whole
line, and nouveau 3d support for nvidea cards, and yes then we still want to
have this check, as there will always be some unsupported cards.

BTW: I've looked at the (F7) version of the script. Does it work with
AIGLX desktops? AFAICS, accelerated 3d should work there, but this is
indirect rendering and glxinfo should give "direct rendering: No". Then
there's the issue of proprietary 3D drivers completely bypassing the
DRI/DRM infrastructure.

Nils

[Debarshi 'Rishi' Ray]

Post by Gérard Milmeister
I wonder if it makes any sense to include OpenGL games in such a Games
Live DVD, that does not provide <beep> drivers.

Why not? OpenGL games run on GPUs for which one has free software
drivers. eg., Intel. Thus one can use such a LiveCD to check the
availability and quality of graphics drivers and hardware before
buying a new computer.

Cheers,
Debarshi

[Hans de Goede]

Post by Gérard Milmeister

Post by Hans de Goede
This is esp. important for the Games Live DVD, as there people will not have
those other <beep> drivers available.

I wonder if it makes any sense to include OpenGL games in such a Games
Live DVD, that does not provide <beep> drivers.

Yes it does, as OpenGL games will work fine on all integrated intel graphics
(lots of systems) and on all pre r5xx radeons (quite a few systems).

And who knows, with Fedora 9 we might have radeon 3d support over the whole
line, and nouveau 3d support for nvidea cards, and yes then we still want to
have this check, as there will always be some unsupported cards.

Regards,

Hans

[Alexander Boström]

Post by Hans de Goede
The idea here is that an error dialog is better then trying to click the quit
menu option while the mouse is jumping from the right edge of the screen to the
left edge (mouse navigation is anything but easy at 3 fps).

Actually, I would consider that a bug in the application/game. If it's
unable to render quickly enough to be usable it should either figure
that out before putting the user in such a position or exit gracefully
before the user gets frustrated and forces a hard reboot. A proper
explanation of what happened is good, of course.

/abo

[Matthew Miller]

Post by Alexander Boström
Actually, I would consider that a bug in the application/game. If it's

Yeah, but since there's thousands of programs with that "bug", the wrapper
is a nicer solution.

[Jochen Schmitt]

Post by Matthew Miller

Post by Alexander Boström
Actually, I would consider that a bug in the application/game. If it's

Yeah, but since there's thousands of programs with that "bug", the wrapper
is a nicer solution.

For me, this wrapper is not a solution, because I have got a error
message. I'm using the
nvidia driver from rpm.livna.org and stellarium is running fine with
this driver.

So I was force to block BZ #304851

Best Regards:

Jochen Schmitt

[Hans de Goede]

Post by Jochen Schmitt

Post by Matthew Miller

Post by Alexander Boström
Actually, I would consider that a bug in the application/game. If it's

Yeah, but since there's thousands of programs with that "bug", the wrapper
is a nicer solution.

For me, this wrapper is not a solution, because I have got a error
message. I'm using the
nvidia driver from rpm.livna.org and stellarium is running fine with
this driver.
So I was force to block BZ #304851

Ugh, I agree this is bad, but not using the wrapper is not the solution, the
wrapper should be fixed. I naively assumed that the nvidea and fglrx drivers
where both using dri as well (I'm pretty sure the fglrx driver is, but I'll
give it a try).

Can you please attach the output of glxinfo for an nvidia card, then I'll try
to come up with a fixed version of the script.

Luckily I put the script in a seperate rpm and did not copy and paste it to a
gazillion game packages, cases like this being exactly the reason to have the
script in one central place.

Regards,

Hans

[dragoran]

Post by Hans de Goede

Post by Jochen Schmitt

Post by Matthew Miller

Post by Alexander Boström
Actually, I would consider that a bug in the application/game. If it's

Yeah, but since there's thousands of programs with that "bug", the wrapper
is a nicer solution.

For me, this wrapper is not a solution, because I have got a error
message. I'm using the
nvidia driver from rpm.livna.org and stellarium is running fine with
this driver.
So I was force to block BZ #304851

Ugh, I agree this is bad, but not using the wrapper is not the solution, the
wrapper should be fixed. I naively assumed that the nvidea and fglrx drivers
where both using dri as well (I'm pretty sure the fglrx driver is, but I'll
give it a try).

fglrx does while nvidia does _NOT_ use dri

[Wart]

Post by dragoran

Post by Hans de Goede

Post by Jochen Schmitt

Post by Matthew Miller

Post by Alexander Boström
Actually, I would consider that a bug in the application/game. If it's

Yeah, but since there's thousands of programs with that "bug", the wrapper
is a nicer solution.

For me, this wrapper is not a solution, because I have got a error
message. I'm using the
nvidia driver from rpm.livna.org and stellarium is running fine with
this driver.
So I was force to block BZ #304851

Ugh, I agree this is bad, but not using the wrapper is not the solution, the
wrapper should be fixed. I naively assumed that the nvidea and fglrx drivers
where both using dri as well (I'm pretty sure the fglrx driver is, but I'll
give it a try).

fglrx does while nvidia does _NOT_ use dri

Are you sure? On my system with the nvidia binary drivers from livna:

$ glxinfo | grep -i direct
direct rendering: Yes

...and neverball/neverputt work fine with the wrapper.

Now, the nvidia driver does not load the dri module in xorg.conf,
presumably because the binary driver has DRI built-in.

--Wart

[dragoran]

Post by Wart

Post by dragoran
fglrx does while nvidia does _NOT_ use dri

$ glxinfo | grep -i direct
direct rendering: Yes

sure it does provide direct rendering else the driver would be useless ;)

Post by Wart
...and neverball/neverputt work fine with the wrapper.

ok looked at the warpper code and it seems that it just looks for
direct rendering: Yes in the glxinfo output which should work on any
card providing direct rendering.

Post by Wart
Now, the nvidia driver does not load the dri module in xorg.conf,
presumably because the binary driver has DRI built-in.

no, there are not using the dri/drm infrastructure at all there using their own.

[dragoran]

Post by Wart

Post by dragoran
fglrx does while nvidia does _NOT_ use dri

$ glxinfo | grep -i direct
direct rendering: Yes

sure it does provide direct rendering else the driver would be useless ;)

Post by Wart
...and neverball/neverputt work fine with the wrapper.

ok looked at the warpper code and it seems that it just looks for
direct rendering: Yes in the glxinfo output which should work on any
card providing direct rendering.

Post by Wart
Now, the nvidia driver does not load the dri module in xorg.conf,
presumably because the binary driver has DRI built-in.

no, there are not using the dri/drm infrastructure at all there using their own.

[Wart]

Post by dragoran

Post by Hans de Goede

Post by Jochen Schmitt

Post by Matthew Miller

Post by Alexander Boström
Actually, I would consider that a bug in the application/game. If it's

Yeah, but since there's thousands of programs with that "bug", the wrapper
is a nicer solution.

For me, this wrapper is not a solution, because I have got a error
message. I'm using the
nvidia driver from rpm.livna.org and stellarium is running fine with
this driver.
So I was force to block BZ #304851

Ugh, I agree this is bad, but not using the wrapper is not the solution, the
wrapper should be fixed. I naively assumed that the nvidea and fglrx drivers
where both using dri as well (I'm pretty sure the fglrx driver is, but I'll
give it a try).

fglrx does while nvidia does _NOT_ use dri

Are you sure? On my system with the nvidia binary drivers from livna:

$ glxinfo | grep -i direct
direct rendering: Yes

...and neverball/neverputt work fine with the wrapper.

Now, the nvidia driver does not load the dri module in xorg.conf,
presumably because the binary driver has DRI built-in.

--Wart

[dragoran]

Post by Hans de Goede

Post by Jochen Schmitt

Post by Matthew Miller

Post by Alexander Boström
Actually, I would consider that a bug in the application/game. If it's

Yeah, but since there's thousands of programs with that "bug", the wrapper
is a nicer solution.

For me, this wrapper is not a solution, because I have got a error
message. I'm using the
nvidia driver from rpm.livna.org and stellarium is running fine with
this driver.
So I was force to block BZ #304851

Ugh, I agree this is bad, but not using the wrapper is not the solution, the
wrapper should be fixed. I naively assumed that the nvidea and fglrx drivers
where both using dri as well (I'm pretty sure the fglrx driver is, but I'll
give it a try).

fglrx does while nvidia does _NOT_ use dri

[Hans de Goede]

Post by Jochen Schmitt

Post by Matthew Miller

Post by Alexander Boström
Actually, I would consider that a bug in the application/game. If it's

Yeah, but since there's thousands of programs with that "bug", the wrapper
is a nicer solution.

For me, this wrapper is not a solution, because I have got a error
message. I'm using the
nvidia driver from rpm.livna.org and stellarium is running fine with
this driver.
So I was force to block BZ #304851

Ugh, I agree this is bad, but not using the wrapper is not the solution, the
wrapper should be fixed. I naively assumed that the nvidea and fglrx drivers
where both using dri as well (I'm pretty sure the fglrx driver is, but I'll
give it a try).

Can you please attach the output of glxinfo for an nvidia card, then I'll try
to come up with a fixed version of the script.

Luckily I put the script in a seperate rpm and did not copy and paste it to a
gazillion game packages, cases like this being exactly the reason to have the
script in one central place.

Regards,

Hans

[Jochen Schmitt]

Post by Matthew Miller

Post by Alexander Boström
Actually, I would consider that a bug in the application/game. If it's

Yeah, but since there's thousands of programs with that "bug", the wrapper
is a nicer solution.

For me, this wrapper is not a solution, because I have got a error
message. I'm using the
nvidia driver from rpm.livna.org and stellarium is running fine with
this driver.

So I was force to block BZ #304851

Best Regards:

Jochen Schmitt

[Matthew Miller]

Post by Alexander Boström
Actually, I would consider that a bug in the application/game. If it's

Yeah, but since there's thousands of programs with that "bug", the wrapper
is a nicer solution.

[Hans de Goede]

Hi All,

In preperation for the Games Live DVD, I've created a small bash script which
resides in opengl-games-utils, which is meant to be used as a wrapper around
OpenGL games. If DRI is available this wrapper does nothing, if it isn't it
will show an error dialog, explaining about Free Software and 3D drivers and
then exit.

The idea here is that an error dialog is better then trying to click the quit
menu option while the mouse is jumping from the right edge of the screen to the
left edge (mouse navigation is anything but easy at 3 fps).

This is esp. important for the Games Live DVD, as there people will not have
those other <beep> drivers available.

I've already added usage of this wrapper to all my games that are in the
kickstart file for the Live DVD, and I will file bugs for this against a couple
of the most highprofile games also in the kickstart, in the mean time everyone
please check all your games for OpenGL usage and necessary add the wrapper.

Adding the wrapper is _really_ easy:

Add: "Requires: opengl-games-utils"
Add to %install:
"ln -s opengl-game-wrapper.sh $RPM_BUILD_ROOT%{_bindir}/%{name}-wrapper"
Add "%{_bindir}/%{name}-wrapper" to files
Change the .desktop file Exec entry from "%{name}" to "%{name}-wrapper"
Done!

This all assumes your main binary name == %{name}, otherwise adapt as necessary.

If you already have a wrapper script for one reason or the other, you can
incorperate the checkDriOk function directly into your wrapper, no need todo a
wrapper wrapper, see vegastrike's vegastrike-wrapper.sh CVS file as example.

Regards,

Hans

[Gérard Milmeister]

Post by Hans de Goede
This is esp. important for the Games Live DVD, as there people will not have
those other <beep> drivers available.

I wonder if it makes any sense to include OpenGL games in such a Games
Live DVD, that does not provide <beep> drivers.

[Alexander Boström]

Post by Hans de Goede
The idea here is that an error dialog is better then trying to click the quit
menu option while the mouse is jumping from the right edge of the screen to the
left edge (mouse navigation is anything but easy at 3 fps).

Actually, I would consider that a bug in the application/game. If it's
unable to render quickly enough to be usable it should either figure
that out before putting the user in such a position or exit gracefully
before the user gets frustrated and forces a hard reboot. A proper
explanation of what happened is good, of course.

/abo