Discussion:
Please modify your OpenGL using games to use opengl-games-utils
(too old to reply)
Hans de Goede
2007-09-25 11:50:00 UTC
Permalink
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
2007-09-25 12:15:16 UTC
Permalink
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.
--
G?rard Milmeister
Langackerstrasse 49
CH-8057 Z?rich
Debarshi 'Rishi' Ray
2007-09-25 12:20:07 UTC
Permalink
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
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
Richi Plana
2007-09-25 16:41:26 UTC
Permalink
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
2007-09-25 16:45:53 UTC
Permalink
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
2007-09-25 16:55:19 UTC
Permalink
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
2007-09-25 17:23:26 UTC
Permalink
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
2007-09-25 17:57:18 UTC
Permalink
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
2007-09-25 18:47:48 UTC
Permalink
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
2007-10-01 19:29:53 UTC
Permalink
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.
--
Regards,
Doncho N. Gunchev, GPG key ID: 0EF40B9E, Key server: pgp.mit.edu
Ian Chapman
2007-10-01 20:39:15 UTC
Permalink
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.
--
Ian Chapman.
dragoran
2007-10-01 21:30:32 UTC
Permalink
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
2007-10-02 15:05:38 UTC
Permalink
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
2007-10-03 07:13:28 UTC
Permalink
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
--
Regards,
Doncho N. Gunchev, GPG key ID: 0EF40B9E, Key server: pgp.mit.edu
Hans de Goede
2007-10-03 13:24:30 UTC
Permalink
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
2007-10-03 22:49:03 UTC
Permalink
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 :-)
--
Regards,
Doncho N. Gunchev, GPG key ID: 0EF40B9E, Key server: pgp.mit.edu
Doncho N. Gunchev
2007-10-03 22:49:03 UTC
Permalink
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 :-)
--
Regards,
Doncho N. Gunchev, GPG key ID: 0EF40B9E, Key server: pgp.mit.edu
Hans de Goede
2007-10-03 13:24:30 UTC
Permalink
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
2007-10-03 07:13:28 UTC
Permalink
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
--
Regards,
Doncho N. Gunchev, GPG key ID: 0EF40B9E, Key server: pgp.mit.edu
dragoran
2007-10-01 21:30:32 UTC
Permalink
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
2007-10-02 15:05:38 UTC
Permalink
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
2007-10-01 20:39:15 UTC
Permalink
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.
--
Ian Chapman.
Doncho N. Gunchev
2007-10-01 19:29:53 UTC
Permalink
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.
--
Regards,
Doncho N. Gunchev, GPG key ID: 0EF40B9E, Key server: pgp.mit.edu
Jeff Spaleta
2007-09-25 17:57:18 UTC
Permalink
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
2007-09-25 18:47:48 UTC
Permalink
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
2007-09-25 17:23:26 UTC
Permalink
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
2007-09-25 16:45:53 UTC
Permalink
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
2007-09-25 16:55:19 UTC
Permalink
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
2007-09-25 16:41:26 UTC
Permalink
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
2007-09-25 12:18:22 UTC
Permalink
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
2007-09-28 16:26:16 UTC
Permalink
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
--
Nils Philippsen / Red Hat / nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
Hans de Goede
2007-10-03 13:26:55 UTC
Permalink
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
2007-10-03 15:19:43 UTC
Permalink
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
2007-10-03 15:19:43 UTC
Permalink
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
2007-10-03 13:26:55 UTC
Permalink
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
2007-09-28 16:26:16 UTC
Permalink
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
--
Nils Philippsen / Red Hat / nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
Debarshi 'Rishi' Ray
2007-09-25 12:20:07 UTC
Permalink
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
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
Hans de Goede
2007-09-25 12:18:22 UTC
Permalink
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
2007-09-25 13:44:44 UTC
Permalink
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
2007-09-25 15:23:15 UTC
Permalink
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.
--
Matthew Miller mattdm at mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Jochen Schmitt
2007-09-25 15:37:30 UTC
Permalink
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
2007-09-25 17:24:52 UTC
Permalink
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
2007-10-01 19:44:20 UTC
Permalink
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
2007-10-01 19:53:57 UTC
Permalink
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
2007-10-01 20:04:08 UTC
Permalink
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
2007-10-01 20:04:08 UTC
Permalink
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
2007-10-01 19:53:57 UTC
Permalink
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
2007-10-01 19:44:20 UTC
Permalink
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
2007-09-25 17:24:52 UTC
Permalink
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
2007-09-25 15:37:30 UTC
Permalink
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
2007-09-25 15:23:15 UTC
Permalink
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.
--
Matthew Miller mattdm at mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Hans de Goede
2007-09-25 11:50:00 UTC
Permalink
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
2007-09-25 12:15:16 UTC
Permalink
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.
--
G?rard Milmeister
Langackerstrasse 49
CH-8057 Z?rich
Alexander Boström
2007-09-25 13:44:44 UTC
Permalink
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
Continue reading on narkive:
Loading...