Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 324473 [details] Workaround: make gpm mouse device readable for all users Description of problem: SDL apps in framebuffer cannot use gpm mouse. An attempt to run an SDL application (even one which does not require mouse support) returns the following error: Could not initialize SDL: Unable to open mouse. Version-Release number of selected component (if applicable): All How reproducible: Always Steps to Reproduce: 1. Ensure you have booted with framebuffer support enabled 2. Check gpm has been initialised 3. Switch to a tty without an X server, and attempt to run an SDL application (e.g. uqm) Actual results: Application fails to stat mouse device (see above) Expected results: SDL stats mouse, initialises, and application runs Additional info: The mouse device created by gpm is by default only readable for root. Changing permissions so that all users can read the mouse device (see attached patch) resolves the problem. I've successfully used this workaround/fix for a couple of months, with no problems observed. However, I'm not sure if there's a good reason for these default permissions (in which case SDL has a bug, not gpm).
Hello, device /dev/input/mice isn't created by gpm but by udev. Also udev's rule sets access permission to that device, so changing its permission in gpm's init script isn't good idea. Furthermore, this error message is displayed even when gpm is stopped. So in my opinion this isn't bug in gpm at all. (better workaround, in case that you don't need a mouse, is set environment variable SDL_NOMOUSE=1) I'm reassigning this to SDL, so the maintainer can make a comment.
Thanks Zdenek. For me, SDL applications report the same error under X when I have no mouse support. Everything is fine when using an X server, mouse input is enabled, and the relevant mouse device(s) are readable by all users (as they are by default). (Unfortunately I do need a mouse for some apps, so I'm stuck with changing permissions in init scripts.)
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Bug still present in Fedora 11; changed version to 11.
Still exist on rawhide
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
There is nothing SDL can do about this. The device with the permissions are handled by udev. Assigning to udev.
Solution could be: KERNEL=="mouse*|mice*", ENV{ACL_MANAGE}="1" Don't know what security problems could arise with that.
Can't make this a default policy. Sorry.
The bug is still present in Fedora 13, 14, 15, 19, 20, 22, 24 and 25. Please provide a workaround or fix, regardless of the currently supported version.