Re: pbbuttonsd beta on new Powerbook5,8
Hello Michael, On 26 Jan, this message from Michael Schmitz echoed through cyberspace: >> Things to check: >> >> - whether Debian's mouseemu indeed has bad define for KEY_UNKOWN >> (from old kernel), > > You bet it has. After all, the new fn keys were added to input.h only > recently, no? Hmm, KEY_UNKNOWN has been at 240 for quite a while; there was room for more keys before it. Specifically, it has not changed when the last buttons were added, which were the KBD illum keys (added sometime around june 2004). This is in kernel 2.6, so if mouseemu was built against 2.6 headers, then it is unlikely there would be a problem. Now, 2.4 is another story. I just checked 2.4.22 (ok, that one is _old_), and it has KEY_UNKNOWN at 220, _before_ even the ILLUM backlight keys. 2.4.28 also still has it at 220; and I don't expext it to change after that. Now, I have not tried whether mouseemu even builds at all against 2.4 headers, and I have no idea if it is easily possible to have 2.4 headers under /usr/include/ on a reasonably current Debian system. Should there be a build dependancy for mouseemu on 2.6 headers? But on the other hand, I just tried to check what value of KEY_UNKNOWN is compiled into mouseemu-0.15-2, and I seem to have found that it is indeed 240, the correct value. So something else must be different in the 0.15-2 deb vs. my locally compiled version. Cheers Michel - Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes|Ask Questions. Make Mistakes. L-1710 Luxembourg | email [EMAIL PROTECTED]| http://www.cpu.lu/~mlan| Learn Always. " -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
> Things to check: > > - whether Debian's mouseemu indeed has bad define for KEY_UNKOWN (from > old kernel), You bet it has. After all, the new fn keys were added to input.h only recently, no? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
Hello Matthias, On 23 Jan, this message from Matthias Grimm echoed through cyberspace: >> That doesn't seem to work. Input devices with mouseemu stopped: >> [...] >> pbbuttonsd opens event0 and event2 only. X has event3 and mice open. > > Where have you this information from? /proc ? >From lsof (devices opened by each process) and /sys (mapping between event devices and HID devices): # lsof|grep input # for i in `ls -d /sys/class/input/input*`; > do echo "$i: `cat $i/name`"; ls -d $i/event*; > done # >> So no problem to be expected here, is there? And pbbuttonsd should be >> able to detect buttons 2&3 as activity, in contrast to mouse movement >> and button1 (whose event dev is locked by synaptics), since those are >> created on the new uinput event device, accessible to pbbuttonsd? I >> haven't noticed this, but I would need to check. > > In theory this should all work fine :-) I am now running: - pbbuttonsd 0.7.3-5g, - mouseemu 0.15-2, recompiled locally against headers containg 'latest' definition of KEY_UNKOWN All this results in (hooray...) a working system as expected after a reboot. As expected meaning Fn'ed keys are all working, and activity is indeed detected except for first mouse button and mouse movement, which are grabbed exclusively by the synaptics driver. Things to check: - whether Debian's mouseemu indeed has bad define for KEY_UNKOWN (from old kernel), - whether going back to that version of mouseemu renders Fn'ed keys non-working again, - whether all this survives a sleep cycle. More info as time permits :-) Cheers, and thanks all for your comments Michel - Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes|Ask Questions. Make Mistakes. L-1710 Luxembourg | email [EMAIL PROTECTED]| http://www.cpu.lu/~mlan| Learn Always. " -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
On Mon, 23 Jan 2006 00:00:19 +0100 (CET) Mich Lanners <[EMAIL PROTECTED]> wrote: > > devices will be automatically added or > > removed as soon as they appear or vanish. > > That doesn't seem to work. Input devices with mouseemu stopped: > [...] > pbbuttonsd opens event0 and event2 only. X has event3 and mice open. Where have you this information from? /proc ? There might be an error in pbbuttonsd but I just checked interoperability with mouseemu and this is the result (Pbbuttonsd beta with debug output): # src/pbbuttonsd INFO: DBG: InputSource added: 00010001 <- input devices scan at startup INFO: DBG: InputSource added: 000122c4 <- the numbers are vendor/product INFO: DBG: InputSource added: 0001771f INFO: DBG: InputSource added: 00013301 INFO: DBG: InputSource added: 001f0001 INFO: DBG: Machine: 31<- machine code of my ancient PowerBook INFO: DBG: Keyboard: ADB INFO: DBG: Trackpad: ADB INFO: DBG: Ambient: None INFO: DBG: InputSource added: <- internal input source INFO: Soundsystem angefordert: auto, erkannt: ALSA und letztlich aktiviert: ALSA. INFO: Speichern der Konfig auf /usr/local/etc/pbbuttonsd.conf freigegeben. pbbuttonsd 0.7.3-6g: iBook/G3 PB Pismo/G4 PB Titanium (PMU version: 12) INFO: Script '/usr/local/etc/power/pmcs-pbbuttonsd performance ac ' gestartet und normal beendet INFO: DBG: InputSource added: 7fe9d570 <- another internal input source Mouse: Rel-X 0, Rel-Y -1 <- some mouse movement Mouse: Rel-X -1, Rel-Y 0 Mouse: Rel-X 0, Rel-Y -1 Mouse: Rel-X 0, Rel-Y -1 [...] INFO: DBG: InputSource added: 001f001f <- mouseemu started, pbbuttonsd INFO: DBG: InputSource added: 001f001e <- detected 2 new input devices Mouse: Rel-X -1, Rel-Y 0 <- some more mouse movement Mouse: Rel-X -1, Rel-Y 0 Mouse: Rel-X -1, Rel-Y 0 [...] INFO: DBG: InputSource received G_IO_IN <- pbbuttonsd received CTRL-C INFO: DBG: InputSource removed: 7fe9d570 INFO: DBG: InputSource removed: 00010001 INFO: DBG: InputSource removed: 000122c4 INFO: DBG: InputSource removed: 0001771f INFO: DBG: InputSource removed: 00013301 INFO: DBG: InputSource removed: 001f0001 INFO: DBG: InputSource removed: INFO: DBG: InputSource removed: 001f001f INFO: DBG: InputSource removed: 001f001e Key events were also recognized but not printed in the debug log. On the other hand I got some strange behaviour with mouseemu running: 1. F10 in X doesn't work anymore 2. paste with middle mouse button (F11, kernel mouse button emulation) opens the context menu ?!? After stopping mouseemu, everything works as usual again. I never had this before. > mouseemu has event0, event1 and event2 open, as well as uinput (two times). > However, pbbuttonsd does _not_ seem to reopen any devices, in particular > after a few minutes it still hasn't opened the uinput event devices. Could you compile pbbuttonsd with debug information (--enable-debug) and check if the debug output confirms your observation? There might be a bug in pbbuttonsd that I doesn't see on my machine (would not be the first one :-)) > > Mouseemu exclusively locks all input devices related to mice for full > > control. After that it routes the mouse events through a newly created > > input device (or two of them). This way it can filter out unwanted > > mouse events or create new ones. Pbbuttonsd can't access the locked > > event devices anymore but it uses the newly created uinput devices > > instead. You won't see any difference in behaviour. > > So no problem to be expected here, is there? And pbbuttonsd should be > able to detect buttons 2&3 as activity, in contrast to mouse movement > and button1 (whose event dev is locked by synaptics), since those are > created on the new uinput event device, accessible to pbbuttonsd? I > haven't noticed this, but I would need to check. In theory this should all work fine :-) > It still doesn't explain why Fn'ed keys aren't detected by pbbuttonsd > anymore while mouseemu is running. I had similar experiences (see above). Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
> > /sys/class/input/input26/name: Mouseemu virtual keyboard > /sys/class/input/input26/event5 > /sys/class/input/input27/name: Mouseemu virtual mouse > /sys/class/input/input27/event6 > > mouseemu has event0, event1 and event2 open, as well as uinput (two times). > However, pbbuttonsd does _not_ seem to reopen any devices, in particular > after a few minutes it still hasn't opened the uinput event devices. Hopefully the rescan doesn't discard the input devices in the high twenties :-) Why is it that input device numbers don't get reused BTW? Someone still keeping them open? > It still doesn't explain why Fn'ed keys aren't detected by pbbuttonsd > anymore while mouseemu is running. > > Is mouseemu also locking the keyboard exclusively? That, plus the fact > that pbbuttonsd isn't opening the uinput event dev's, would be the > explanation then. Yep, that's what mouseemu needs to do - otherwise you'd get all events twice. Even if the input code discards duplicate events, you'd still get to see the button emulation events as key events. Very annoying. See my other mail - mouseemu might need a recompile if the USB keyboard special keys got assigned codes above the old KEY_UNKNOWN value. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
> >> Well, no luck, it's not that easy. Neither the fact that mouseemu is > >> running in parallel, nor the order in which thez are started seems to > >> matter. > > Correction: it does seem that running mouseemu blocks the special keys, > as well as blocking pbbuttonsd's keyboard activity detection. > > > > And there's been problems with the number of event devices being > > checked by either mouseemu or pbbuttonsd (forgot which). And there may > > be input devices that are fake (no real device attached, I have two > > such). Check > > /sys/class/input/input*/name to see what is what, and if the virtual > > devices mouseemu created are really there. > > All 32 event devices are there (udev disabled). mouseemu does create > it's event device corresponding to /dev/input/uinput. If mouseemu > wouldn't relay keyboard events, the keyboard wouldn't work at all. Unless mouseemu fails to accept the new keyboard as keyboard ... a simple thing to try: change the register_inputhandler call for the keyboard handler to pass 0 (zero) as last argument. That keeps it from grabbing the keyboard for exclusive use. May result in each key being sent twice, so don't do this unless you can ssh into the machine :-) > It seems to be more a problem of mouseemu filtering out _some_ events? OK, that's something to hunt for. mouseemu does in fact set up the virtual keyboard for passthrough of all events except the button emulation events, so it would seem the special keys never make it to mouseemu. The event mask for the virtual keyboard is set up to KEY_UNKNOWN - maybe that constant got changed by the new special key patch? Try building mouseemu using your own kernel headers in that case. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
Hello Matthias, [writing this mail a second time, powerbook went to sleep and crashed on wake while replying. Arghhh...] On 22 Jan, this message from Matthias Grimm echoed through cyberspace: > There are a couple of applications fiddle around with /dev/input/event > so I try to bring some light into it. Thanks a lot for that, it helped tremendously. > Udev is responsible for creating an /dev/input/event% device for each > HID. Udev is the most comfortable way to have up-to-date devices > in /dev. If you don't have udev running, be sure that each HID is > represented by an event devive in /dev/input/. udev disabled here, and all 32 event devices exist in the statuc /dev. > Pbbuttonsd opens all /dev/input/event% devices and uses them for input > (at least to reset the user idle timer). If autorescan = yes Checked, I have that. > devices will be automatically added or > removed as soon as they appear or vanish. That doesn't seem to work. Input devices with mouseemu stopped: /sys/class/input/input5/name: Apple Computer Apple Internal Keyboard / Trackpad /sys/class/input/input5/event2 /sys/class/input/input6/name: appletouch /sys/class/input/input6/event3 /sys/class/input/input7/name: Apple Computer Apple Internal Keyboard / Trackpad /sys/class/input/input7/event4 /sys/class/input/input8/name: HID 05ac:1000 /sys/class/input/input8/event0 /sys/class/input/input9/name: HID 05ac:1000 /sys/class/input/input9/event1 pbbuttonsd opens event0 and event2 only. X has event3 and mice open. With mouseemu running, I have these devices: /sys/class/input/input26/name: Mouseemu virtual keyboard /sys/class/input/input26/event5 /sys/class/input/input27/name: Mouseemu virtual mouse /sys/class/input/input27/event6 /sys/class/input/input5/name: Apple Computer Apple Internal Keyboard / Trackpad /sys/class/input/input5/event2 /sys/class/input/input6/name: appletouch /sys/class/input/input6/event3 /sys/class/input/input7/name: Apple Computer Apple Internal Keyboard / Trackpad /sys/class/input/input7/event4 /sys/class/input/input8/name: HID 05ac:1000 /sys/class/input/input8/event0 /sys/class/input/input9/name: HID 05ac:1000 /sys/class/input/input9/event1 mouseemu has event0, event1 and event2 open, as well as uinput (two times). However, pbbuttonsd does _not_ seem to reopen any devices, in particular after a few minutes it still hasn't opened the uinput event devices. After booting the powerbook again (tomorrow) I need to check whether stopping/starting pbbuttonsd makes it open the uinput event devices. > Mouseemu exclusively locks all input devices related to mice for full > control. After that it routes the mouse events through a newly created > input device (or two of them). This way it can filter out unwanted > mouse events or create new ones. Pbbuttonsd can't access the locked > event devices anymore but it uses the newly created uinput devices > instead. You won't see any difference in behaviour. So no problem to be expected here, is there? And pbbuttonsd should be able to detect buttons 2&3 as activity, in contrast to mouse movement and button1 (whose event dev is locked by synaptics), since those are created on the new uinput event device, accessible to pbbuttonsd? I haven't noticed this, but I would need to check. > Synaptics Trackpad driver, often used on recent PowerBooks, also locks > all mouse input events for exclusive use but in contrast to mouseemu > it doesn't create an uinput device to let other applications receive > mouse events. This problem is well known and Luca Bigliardi prepared a > patch to work around this problem. Furthermore some people including > Luca are working on a final solution of this problem. If you used the > unmodified synaptics driver you would deprive pbbuttonsd and mouseemu > of mouse events. OK, work to be done here. That explains why mouse movement isn't detected as activity. > I hope this will help to identify where the problems come from or at > least give some hinte where to look at next. It still doesn't explain why Fn'ed keys aren't detected by pbbuttonsd anymore while mouseemu is running. Is mouseemu also locking the keyboard exclusively? That, plus the fact that pbbuttonsd isn't opening the uinput event dev's, would be the explanation then. Thanks to all so far :-) Cheers Michel PS Does anybody know what all those input devices correspond to? - Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes|Ask Questions. Make Mistakes. L-1710 Luxembourg | email [EMAIL PROTECTED]| http://www.cpu.lu/~mlan| Learn Always. " -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
Hi all, On 22 Jan, this message from Michael Schmitz echoed through cyberspace: > Well, the 'mouseemu eats the CPU' bug has been popping up on occasion, > I thought we had fixed that by now. Doesn't seem to be the case... >> Well, no luck, it's not that easy. Neither the fact that mouseemu is >> running in parallel, nor the order in which thez are started seems to >> matter. Correction: it does seem that running mouseemu blocks the special keys, as well as blocking pbbuttonsd's keyboard activity detection. > There's a possible race between creation of the uinput device mouseemu > uses to forward events, and the opening of this device by later apps. Obvious. However pbbuttonsd does rescan devices, so after the rescan interval it will catch changes in event devices. > And there's been problems with the number of event devices being > checked by either mouseemu or pbbuttonsd (forgot which). And there may > be input devices that are fake (no real device attached, I have two > such). Check > /sys/class/input/input*/name to see what is what, and if the virtual > devices mouseemu created are really there. All 32 event devices are there (udev disabled). mouseemu does create it's event device corresponding to /dev/input/uinput. If mouseemu wouldn't relay keyboard events, the keyboard wouldn't work at all. It seems to be more a problem of mouseemu filtering out _some_ events? > Then check which of these > pbbuttonsd uses, and if there's any events going over those devices. > This may sound fuzzy, or even obvious, but I can't give more specific > hints off the cuff... As it clearly is mouseemu related, I'll check that path. >> There is one change, though, I replaced the earlier FN-key patch >> (http://patchwork.ozlabs.org/linuxppc/patch?id=3856) with the newer >> one (http://patchwork.ozlabs.org/linuxppc/patch?id=4127). But I can't >> se what impact this can have on event detection. > > None, I'd hope. But it seems the earlier patch simply didn't work. Anyway, that part is working now. Thanks, and cheers Michel - Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes|Ask Questions. Make Mistakes. L-1710 Luxembourg | email [EMAIL PROTECTED]| http://www.cpu.lu/~mlan| Learn Always. " -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
On Sun, 22 Jan 2006 14:34:54 +0100 (CET) Michael Schmitz <[EMAIL PROTECTED]> wrote: > > Well, no luck, it's not that easy. Neither the fact that mouseemu is > > running in parallel, nor the order in which thez are started seems to > > matter. There are a couple of applications fiddle around with /dev/input/event so I try to bring some light into it. Udev is responsible for creating an /dev/input/event% device for each HID. Udev is the most comfortable way to have up-to-date devices in /dev. If you don't have udev running, be sure that each HID is represented by an event devive in /dev/input/. Pbbuttonsd opens all /dev/input/event% devices and uses them for input (at least to reset the user idle timer). If autorescan = yes (which should be set by default now), devices will be automatically added or removed as soon as they appear or vanish. So called 'fake' devices, created for example by the uinput kernel driver, will be used as usual. Pbbuttonsd makes no difference between a real event device or one from uinput. With the new beta version there is no limit anymore for used event devices. In worst case all 32 devices will be read. Mouseemu exclusively locks all input devices related to mice for full control. After that it routes the mouse events through a newly created input device (or two of them). This way it can filter out unwanted mouse events or create new ones. Pbbuttonsd can't access the locked event devices anymore but it uses the newly created uinput devices instead. You won't see any difference in behaviour. Synaptics Trackpad driver, often used on recent PowerBooks, also locks all mouse input events for exclusive use but in contrast to mouseemu it doesn't create an uinput device to let other applications receive mouse events. This problem is well known and Luca Bigliardi prepared a patch to work around this problem. Furthermore some people including Luca are working on a final solution of this problem. If you used the unmodified synaptics driver you would deprive pbbuttonsd and mouseemu of mouse events. I hope this will help to identify where the problems come from or at least give some hinte where to look at next. Best Regards Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
> >> opens them all. But event4 ... event31 all report ENODEV. > > > > Just wondering ... Does the USB keyboard driver report events at all? > > I'll check that with an external keyboard ASAP. > > I have activity detection working now. I have no idea what made it work, > might be something to do with mouseemu (which was stopped at that moment > because it ate 100% CPU). But it's not determinsitic; I first thought it > was a plain incompatibility with mouseemu, so stopping that should make > everything work. Well, the 'mouseemu eats the CPU' bug has been popping up on occasion, I thought we had fixed that by now. > Well, no luck, it's not that easy. Neither the fact that mouseemu is > running in parallel, nor the order in which thez are started seems to > matter. There's a possible race between creation of the uinput device mouseemu uses to forward events, and the opening of this device by later apps. And there's been problems with the number of event devices being checked by either mouseemu or pbbuttonsd (forgot which). And there may be input devices that are fake (no real device attached, I have two such). Check /sys/class/input/input*/name to see what is what, and if the virtual devices mouseemu created are really there. Then check which of these pbbuttonsd uses, and if there's any events going over those devices. This may sound fuzzy, or even obvious, but I can't give more specific hints off the cuff... > There is one change, though, I replaced the earlier FN-key patch > (http://patchwork.ozlabs.org/linuxppc/patch?id=3856) with the newer one > (http://patchwork.ozlabs.org/linuxppc/patch?id=4127). But I can't se > what impact this can have on event detection. None, I'd hope. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
Hi all, On 20 Jan, this message from Michael Schmitz echoed through cyberspace: >> So I'm back to statuc device files, and I previously had event0 .. >> event3. I have created the other ones til 31, and indeed pbbuttonsd >> opens them all. But event4 ... event31 all report ENODEV. > > Just wondering ... Does the USB keyboard driver report events at all? > I'll check that with an external keyboard ASAP. I have activity detection working now. I have no idea what made it work, might be something to do with mouseemu (which was stopped at that moment because it ate 100% CPU). But it's not determinsitic; I first thought it was a plain incompatibility with mouseemu, so stopping that should make everything work. Well, no luck, it's not that easy. Neither the fact that mouseemu is running in parallel, nor the order in which thez are started seems to matter. There is one change, though, I replaced the earlier FN-key patch (http://patchwork.ozlabs.org/linuxppc/patch?id=3856) with the newer one (http://patchwork.ozlabs.org/linuxppc/patch?id=4127). But I can't se what impact this can have on event detection. > I'm still on 2.6.15rc5, but udev works OK there. It's been a bit dodgy > to get started IIRC, but that's been a while back. Concerning udev, I'll recheck and file bugs as appropriate. Cheers Michel - Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes|Ask Questions. Make Mistakes. L-1710 Luxembourg | email [EMAIL PROTECTED]| http://www.cpu.lu/~mlan| Learn Always. " -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
> So I'm back to statuc device files, and I previously had event0 .. > event3. I have created the other ones til 31, and indeed pbbuttonsd > opens them all. But event4 ... event31 all report ENODEV. Just wondering ... Does the USB keyboard driver report events at all? I'll check that with an external keyboard ASAP. I'm still on 2.6.15rc5, but udev works OK there. It's been a bit dodgy to get started IIRC, but that's been a while back. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
On Fri, Jan 20, 2006 at 12:42:08AM +0100, Mich Lanners wrote: > Hi Sven, > > What distribution/kernel/udev are you running ? > > Debian etch aka testing, 2.6.15 kernel.org plus fn and trackpad > patrches, udev 0.076-6 (the one currently in testing). Can you try installing the sid udev (0.81-1) ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
On Fri, Jan 20, 2006 at 12:42:08AM +0100, Mich Lanners wrote: > Hi Sven, > > On 20 Jan, this message from Sven Luther echoed through cyberspace: > > On Fri, Jan 20, 2006 at 09:11:37AM +1100, Benjamin Herrenschmidt wrote: > >> > However, I have another problem: it seems that pbbuttonsd can't > >> > detect activity. > >> > > [snip] > >> > > >> > Can anyone confirm this behaviour? Any fixes available? > >> > >> I had this problem with some kernels (I think 2.6.14 had the issue) > >> and/or udev version problems (check that you have the > >> various /dev/input/ entries, events mouse and kbd, I think it was > >> missing some of the events devices) > > > > Current 2.6.15 debian kernel with a sarge userland exhibit the > > problem. The mouse events work fine, but indeed the keyboard events > > don't get recognized as activity. > > > > The above comment from Benjamin Herrenschmidt made me remember that it > > is not recomended to run older udev with newer kernel, which means i > > should re-backport a newer version of udev. > > > > What distribution/kernel/udev are you running ? > > Debian etch aka testing, 2.6.15 kernel.org plus fn and trackpad > patrches, udev 0.076-6 (the one currently in testing). > > As I said in reply to Ben, my udev is not working anyway. Mmm, did you already file a bug against udev for this ? > Thanks, and cheers > > Michel > > PS Sven, mind using a newer kernel on your daily d-i builds, so that > recent Powerbooks can be installed with that? Tomorrow's daily build should have 2.6.15-1. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
Hi Sven, On 20 Jan, this message from Sven Luther echoed through cyberspace: > On Fri, Jan 20, 2006 at 09:11:37AM +1100, Benjamin Herrenschmidt wrote: >> > However, I have another problem: it seems that pbbuttonsd can't >> > detect activity. >> > [snip] >> > >> > Can anyone confirm this behaviour? Any fixes available? >> >> I had this problem with some kernels (I think 2.6.14 had the issue) >> and/or udev version problems (check that you have the >> various /dev/input/ entries, events mouse and kbd, I think it was >> missing some of the events devices) > > Current 2.6.15 debian kernel with a sarge userland exhibit the > problem. The mouse events work fine, but indeed the keyboard events > don't get recognized as activity. > > The above comment from Benjamin Herrenschmidt made me remember that it > is not recomended to run older udev with newer kernel, which means i > should re-backport a newer version of udev. > > What distribution/kernel/udev are you running ? Debian etch aka testing, 2.6.15 kernel.org plus fn and trackpad patrches, udev 0.076-6 (the one currently in testing). As I said in reply to Ben, my udev is not working anyway. Thanks, and cheers Michel PS Sven, mind using a newer kernel on your daily d-i builds, so that recent Powerbooks can be installed with that? - Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes|Ask Questions. Make Mistakes. L-1710 Luxembourg | email [EMAIL PROTECTED]| http://www.cpu.lu/~mlan| Learn Always. " -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
Hi Ben, On 20 Jan, this message from Benjamin Herrenschmidt echoed through cyberspace: > On Thu, 2006-01-19 at 23:09 +0100, Mich Lanners wrote: >> However, I have another problem: it seems that pbbuttonsd can't >> detect activity. >> >> While typing, a short while after resuming from sleep, the display is >> dimmed down to level 1. Another while later, if I don't stop >> pbbuttonsd in the mean time, it puts the machine to sleep. All this >> while I'm typing >> >> Can anyone confirm this behaviour? Any fixes available? > > I had this problem with some kernels (I think 2.6.14 had the issue) > and/or udev version problems (check that you have the > various /dev/input/ entries, events mouse and kbd, I think it was > missing some of the events devices) I have serious problems with udev myself; default instal would not create half of the devices half of the time. I'm now at the point of disabling udev (append="UDEV_DISABLED=yes"). It still barks on startup about files it cannot remove because of RO filesystem. Anyway, other issue. So I'm back to statuc device files, and I previously had event0 .. event3. I have created the other ones til 31, and indeed pbbuttonsd opens them all. But event4 ... event31 all report ENODEV. I'm running 2.6.15. I might trz more recent, do you know a version that does compile? I originally tried compiling 2.6.15-git6, but that didn't compile. Thanks, and cheers Michel - Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes|Ask Questions. Make Mistakes. L-1710 Luxembourg | email [EMAIL PROTECTED]| http://www.cpu.lu/~mlan| Learn Always. " -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
On Fri, Jan 20, 2006 at 09:11:37AM +1100, Benjamin Herrenschmidt wrote: > On Thu, 2006-01-19 at 23:09 +0100, Mich Lanners wrote: > > Hi all, > > > > For those who didn't notice, pbbuttonsd just got support for the backlit > > keyboard of the new Powerbooks (post-October 2005). > > > > For me it works fine :-) > > > > However, I have another problem: it seems that pbbuttonsd can't detect > > activity. > > > > While typing, a short while after resuming from sleep, the display is > > dimmed down to level 1. Another while later, if I don't stop pbbuttonsd > > in the mean time, it puts the machine to sleep. All this while I'm > > typing > > > > Can anyone confirm this behaviour? Any fixes available? > > I had this problem with some kernels (I think 2.6.14 had the issue) > and/or udev version problems (check that you have the > various /dev/input/ entries, events mouse and kbd, I think it was > missing some of the events devices) Current 2.6.15 debian kernel with a sarge userland exhibit the problem. The mouse events work fine, but indeed the keyboard events don't get recognized as activity. The above comment from Benjamin Herrenschmidt made me remember that it is not recomended to run older udev with newer kernel, which means i should re-backport a newer version of udev. What distribution/kernel/udev are you running ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbbuttonsd beta on new Powerbook5,8
On Thu, 2006-01-19 at 23:09 +0100, Mich Lanners wrote: > Hi all, > > For those who didn't notice, pbbuttonsd just got support for the backlit > keyboard of the new Powerbooks (post-October 2005). > > For me it works fine :-) > > However, I have another problem: it seems that pbbuttonsd can't detect > activity. > > While typing, a short while after resuming from sleep, the display is > dimmed down to level 1. Another while later, if I don't stop pbbuttonsd > in the mean time, it puts the machine to sleep. All this while I'm > typing > > Can anyone confirm this behaviour? Any fixes available? I had this problem with some kernels (I think 2.6.14 had the issue) and/or udev version problems (check that you have the various /dev/input/ entries, events mouse and kbd, I think it was missing some of the events devices) Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
