Ron <[EMAIL PROTECTED]> writes: [...]
> anyway, it is (otherwise harmless) cruft now and /etc/modprobe-before- > can be safely removed. OK. >> When I added "rmmod wacom; rmmod usbhid" to >> /etc/init.d/gdm, I got X back again (before that X failed to start, >> since the wacom mouse is my primary pointer). > > Please try removing those lines again once you have a clean install > of the >= -7 packages (including the generated module package), and let > me know if it still doesn't work. If by some chance it doesn't, then: Nope, that didn't work. I verified using wacdump: wacdump doesn't recognise anything. > a) Change your XF*^Config-4 to use /dev/input/wacom instead of > whatever /dev/input/event* you have there now. This will free you > from trouble with the order modules and devices are probed. > b) If a) doesn't work: > add: echo 1 > /sys/module/wacom/parameters/rebind > in place of the rmmod ... above, and give me another ping whether > b) works or not :-) hotplug should have already taken care of this > for you by the time X is looking for a core pointer, if not, we should > look at why. No, that still doesn't work. Again, I verified with wacdump, and tried various combinations of things. It seems that usbhid is already loaded by the time that X tries to start, and if usbhid is loaded, I can't seem to get wacom to work, even by echoing 1 to /sys/.../rebind. I really do seem to have to rmmod usbhid. I think I built my kernel with wacom enabled (as a module). Your generated package overwrites that file, but does the rebinding behaviour expect me to have built without wacom enabled? >> Some minor things. Most kernel module source packages (all those I've >> tried other than wacom-kernel-source) seem to install a suitable >> gzipped/bzipped tarball into /usr/src; that makes it convenient to >> switch building on or off. > > I'm not sure exactly what you are doing here, but I do consider having > to shuffle tarballs around to be a bit on the ugly side of good package > management. (aka: if I wanted to juggle tarballs, why do I mess with > .debs) I think it's just that occasionally I find I need to edit files in modules, and it's convenient now and again just to remove the whole thing and untar it. However, you're right that it's of no particular importance---there are other ways of doing the sorts of things that I do. [...] > Except for the fact that the upstream build system ties building the > kernel module very tightly with building the tools to use it. Jens > posted about fixing this recently, so relief is in sight for this > one. That explains that. >> All other module source packages seem to >> cause their packages to be built in /usr/src (well, probably in .. >> relative to where make-kpkg is run). > > This is genuine unspecified behaviour in Debian. I had packages > doing both on my system at the time I first uploaded these, and I > crunched all the factors through my head and decided that using > '..' (relative to where debian/rules was run) was preferable for > more reasons than using $(KSRC)/.. Yes, I can go with that. On the other hand, I'm running make-kpkg, so I expect the packages to be .. relative to where I did that. There's probably no answer that's definitively right. [...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
