On torsdag 26 juli 2007, Gian Paolo Mureddu wrote: > Magnus Vigerlöf escribió: > >> === GDM log === > > > > [...] > > > >> (II) Module already built-in > >> FATAL: Module evdev not found. > > > > [...] > > > > Getting an error opening the wacom device should not cause any problem. > > I'm running KDM myself (Kubuntu 6.10, 7.04) and have never had any > > problems without the tablet connected, GDM might however do things a > > little different (not that I can see why). > > > > The fact that X works but not GDM makes me wonder if there's two separate > > installations (or maybe only configurations) of X that are used for > > different things.. The strance behaviour from the tablet when it's > > connected makes it makes almost more likely (in KDM it works as when I've > > logged in for me). Anyway the 'fatal' message might be worth looking more > > closely at since those usually are worse than 'only' errors. > > > > I know the evdev driver in X has some fishy hotplug-code that can cause > > some grief, but since it complain it can't load it that should not be the > > problem in this case. > > Thanks for your input on this. The above is so because the event device > is built into the kernel, i.e there is no module for it (confirmed by > the kernel configuration file, that's why the double message (II) module > built in and the FATAL sentence). > > >> === Xorg.0.log === > >> > >> (**) Option "Device" "/dev/input/wacom" > >> (EE) xf86OpenSerial: Cannot open device /dev/input/wacom > >> No such file or directory. > >> Error opening /dev/input/wacom : Success > > > > [...] > > > >> In my Xorg.conf file there's an exception for the mice devices to allow > >> X to start even in failure to initialize the device... > >> > >> === Xorg.conf - ServerFlags == > >> > >> Section "ServerFlags" > >> Option "AllowMouseOpenFail" "yes" > >> Option "AIGLX" "on" > >> EndSection > > > > If I remember correctly this was needed before the aggregated > > device /dev/input/mice existed (which always is allowed to be opened > > despite no mice beeing connected). Returning '!Success' from some > > functions will cause the X-server to abort during initialization, but the > > wacom-driver does not return that so that's not the reason for an abort. > > It is rather strange as there seems to be a way in which GDM will abort > should any part of X show a "serious" problem. I've been able to > correlate that to (EE)s present in the Xlog. For example, X loads and > works "fine" if for example the GLX extension is missing on the display, > this will of course generate an error as the module is being requested > by the video driver, but nonetheless X works in 2D just fine. GDM in > presence of this error will abort loading, and will only load when this > has been fixed. The same as with the case with the tablets.
Hmm.. So GDM is really picky about what's in the log, interesting... I think that is something that needs to be raised with those guys.. I'm not sure the wacom driver/project can do much about that as I understand it seems to be a more general problem... > >> Looks like the Wacom InputDevice entries are not being treated as mice > >> devices at all, but other serial devices. I wonder if other users with > >> similar configurations in other distributions have the same issue with > >> GDM or in even Fedora 7 (but with KDM for example), or if this might in > >> any way be imputable to the LinuxWacom driver (which I highly doubt). > >> This poses problem for me, as in the environment I need this working > >> there are more computers than tablets available, and the tablets are > >> constantly moved from one system to another, however, for obvious > >> reasons, a situation like this is a rather serious problem. I wouldn't > >> want to move the whole lab to another distribution, currently we're > >> using FC6 for the production environment, but if this wouldn't be a > >> problem in another distribution with the same features set as Fedora 7, > >> I'd be willing to take my chances... > > > > If you're going to move the tablets around, you'll probably want to ask > > how much hassle you'd like to have when unpluggin/replugging them. Also I > > know I've had problem getting the tablet to work when starting X without > > the tablet connected (=had to restart X to get it working at all). The > > most easy way to get hotplugging to work would be to just switch VT, but > > there are other options which will give you more seamless hotplugging. It > > all depend on your users and how much inconvenience they are willing to > > put up with. > > > > Real hotplugging is still a bit into the future as far as I know, and 73 > > is definitely not there yet. > > I hear you. For the current setup users are instructed to restart X > (from the GDM screen) everytime they attach the tablets. This shouldn't > be required in 1.3 and F7 as supposedly GDM indicates X to restart the > server upon user login. The problem then is that my current problem is > that if the tablet is not present GDM won't load (which is freaking me > out!) and I don't seem to find a way to prevent GDM from checking the > sanity of Xorg, as this seems to be a completely independent behavior. X > loads, but GDM spots an error and wont load. I'm contemplating the > possibility of using an alternate login manager (once I find out how, > without migrating the users to KDE, actually the machines are running > GNOME out of users request) So the problem is really the machines that doesn't have a tablet connected.. Ok, there are two approaches that will give you a input-device that will exists no matter if there is a tablet or not. That way you'll never get those pesky (EE) that mess up your GDM-login.. First; [linuxwacom-devel, Nov-06 'alternative way to support tablet hotplugging']. I think you'll have to lock each 'static' device to a specific tablet model, but I'm not too familiar with it as I'm a user of the second approach. The second is to check out wacomproxy (also an SF-project). You can lock it to up to four different tablet models, or have one that will change as the tablet model changes. These two approaches have an additional benefit as your users can 'forget' to plug in the tablet when they start working and attach it later and then start using it right away without doing anything. It's hotplugging the 'wrong way' but I've found this is currently the best way for me to do it. > >> Do you think there might be a workaround for this? Thus far I've been > >> unable to find any. > > > > There should be a viable solution for you, the first 'problem' is to know > > what your problem is though.. Your system does seem to act a bit fishy.. > > :) > > > > Cheers > > Magnus > > You can say that again! I have to first narrow down the problem with > these test machines. Not that they can't stay as they are for a bit > longer still, but I have to think of an update at some point. Think about the two approaches above. They can eliminate lots of potential problems in terms of pure technical aspects, but also the very important usability aspect of things. Cheers Magnus ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Linuxwacom-discuss mailing list Linuxwacom-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-discuss
