Description of problem: Once xorg.cong is modified to have my Graphire3 USB Wacom tablet working. The tablet must be plugged in to Xorg to load login screen. Once logged in the tablet actually works and is fully usable in Gaim or Inskape. Version-Release number of selected component (if applicable): How reproducible: Everytime Steps to Reproduce: 1. Configure a Wacom tablet in xorg.conf (see attachement) 2. Unplug the tablet 3. Restart Xorg Actual results: The login screen doesn't appear and a error message is shown. Expected results: The screen should appear. Additional info: Xorg log gives (EE) xf86OpenSerial: Cannot open device /dev/input/wacom Due to other bugs #191248 and #230886, I renamed /etc/udev/rules.d/50-wacom.rules to /etc/udev/rules.d/49-wacom.rules to have the /dev/input/wacom shortcut and I removed "%e" which is not supported anymore inside the file.
Created attachment 184861 [details] My xorg.conf file
which version are you using? There's an updated package version in testing updates Please test it and tell me how it goes
I was using linuxwacom-0.7.4_1-2.1 I updated it to linuxwacom-0.7.6.4-3 as you suggested. One good point is that I don't need to touch to /etc/udev/rules.d/60-linuxwacom.rules anymore. When the tablet is connected, a "wacom" link and a "wacom-tablets" folder are created in /dev/input. Anyway, the tablet still needs to be connected to reach the login screen. I still have to comment following lines if I want to start as usual (and without tablet support) Section "ServerLayout" # InputDevice "stylus" "SendCoreEvents" # InputDevice "eraser" "SendCoreEvents" # InputDevice "cursor" "SendCoreEvents" Identifier "single head configuration" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" EndSection
can I get the X log when the tablet is disconnected? I suspect it's not working because you don't have a X pointer device. Try adding Option AllowMouseOpenFail "true" in server flags section
Created attachment 190121 [details] Xorg log when tablet is deconnected I tried adding Option AllowMouseOpenFail "true" and it changed nothing. Here is my Xorg log. The error is at the end of it.
I have the same problem on F7. However it seems to be a problem with GDM instead of linuxwacom. If the tablet is disattached, with approriate settings in xorg.conf, and X is started, the following message is shown: "The greeter application appears to be crashing. Attempting to use a different one." /var/log/messages shows: gdm[9877]: failsafe dialog failed (inhibition: 0 0) gdm[9877]: failsafe dialog failed (inhibition: 0 1) By skipping gdm using the following commands X _can_ be started: init 3 startx (even without the AllowMouseOpenFail setting in xorg.conf) On rawhide with linuxwacom-0.7.8.3-2.fc8 and gdm-2.19.8-3.fc8 it works the same. But it gives a bit more information in /var/log/messages: Sep 10 11:22:18 localhost gdm-binary[2837]: atk-bridge-WARNING: AT_SPI_REGISTRY was not started at session startup. Sep 10 11:22:18 localhost gdm-binary[2837]: atk-bridge-WARNING: IOR not set. Sep 10 11:22:18 localhost gdm-binary[2837]: atk-bridge-WARNING: Could not locate registry Sep 10 11:22:18 localhost gdm-binary[2837]: Gdk-ERROR: The program 'gdm-binary' received an X Window System error.#012This probably reflects a bug in the program.#012The error was 'BadDevice, invalid or uninitialized input device'.#012 (Details: serial 89 error_code 169 request_code 146 minor_code 3)#012 (Note to programmers: normally, X errors are reported asynchronously;#012 that is, you will receive the error a while after causing it.#012 To debug your program, run it with the --sync command line#012 option to change this behavior. You can then get a meaningful#012 backtrace from your debugger if you break on the gdk_x_error() function.)#012aborting... Sep 10 11:22:18 localhost gdm-binary[2717]: WARNING: failsafe dialog failed (inhibitions: 0 0) Sep 10 11:22:18 localhost gdm-binary[2838]: atk-bridge-WARNING: AT_SPI_REGISTRY was not started at session startup. Sep 10 11:22:18 localhost gdm-binary[2838]: atk-bridge-WARNING: IOR not set. Sep 10 11:22:18 localhost gdm-binary[2838]: atk-bridge-WARNING: Could not locate registry Sep 10 11:22:18 localhost gdm-binary[2838]: Gdk-ERROR: The program 'gdm-binary' received an X Window System error.#012This probably reflects a bug in the program.#012The error was 'BadDevice, invalid or uninitialized input device'.#012 (Details: serial 89 error_code 169 request_code 146 minor_code 3)#012 (Note to programmers: normally, X errors are reported asynchronously;#012 that is, you will receive the error a while after causing it.#012 To debug your program, run it with the --sync command line#012 option to change this behavior. You can then get a meaningful#012 backtrace from your debugger if you break on the gdk_x_error() function.)#012aborting... Sep 10 11:22:18 localhost gdm-binary[2717]: WARNING: failsafe dialog failed (inhibitions: 0 1) Sep 10 11:22:18 localhost gdm-binary[2839]: Gtk-WARNING: Ignoring the separator setting
Nicolas, do you get the same thing that Arnout is reporting in comment #6?
Yes I have the same messages in /var/log/message. When I say in the previous comments that "the login screen doesn't appear", in fact I get the French version of "The greeter application appears to be crashing. Attempting to use a different one.". I didn't know how to translate it in English :)
Yes I have the same messages in /var/log/message. When I say in the previous comments that "the login screen doesn't appear", in fact I get the French version of "The greeter application appears to be crashing. Attempting to use a different one.". I didn't know how to translate it in English :) And as Arnout says, if I bypass GDM by using startx, it works even if tablet is not connected.
If the tablet is not connected at X start or unplugged after, then connected once X is already started, The Xorg parameters about the tablet are not used. So the tablet MUST be connected at X start and not unplugged after to be fully usable. It's not nice for a hotplug device !
For the hotplug problem, there's a temporary solution, called 'wdaemon'. It'll be available in FC-6 extras/F-7/rawhide soon.
I'm adding the gdm maintainer to the Cc list, as this appears to be a gdm thing, according to comment #6 and comment #8
If you add AddGtkModules=false to the [daemon] section of /etc/gdm/custom.conf, does the problem go away? Can you add Enable=true to the [debug] section of custom.conf, reproduce the problem and attach /var/log/messages ?
Nothing changed. I've got the same messages as in comment #6 and comment #8.
can you run gdm-restart ? changes to the config file don't take affect immediately.
Created attachment 194561 [details] Xorg log
Created attachment 194571 [details] GDM part of /var/log/message Indeed it works once restarted :) Here are my Xorg log and the messages relative to GDM
Created attachment 194581 [details] Xorg log tail did not returns enough data
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'. 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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.