mouseemu prevents detection of Power button event

# Automatically generated email from bts, devscripts version 2.8.14
reassign 304734 mouseemu

Hi

On Fri, Apr 15, 2005 at 02:12:49AM +0100, Paul Brossier wrote:
> Package: pbbuttonsd
> Version: 0.6.7-1
> Severity: normal
>
> I'm not sure which of the two causes problem. If i stop mouseemu, i can
> access the pbbutonsd keys again. This happens with 0.6.6-3 and 0.6.7-1.

I can't reproduce this with pbbuttonsd 0.6.6-3. For me pbbuttonsd keys
don't stop working. Does this only happen with mouseemu 0.15-2 or also
with older versions? Do all keys stop working or only some? Does the order
of starting pbbuttonsd and mouseemu matter?

And why did you reassign this bug to mouseemu? There is no reason mentioned
in the bug log. Please make sure that all relevant information is also in the
bug log because I don't have access to private conversation between you and
Frank.

Gaudenz

>
> On my ibook i use the following settings:
>
> $ grep Key\ /etc/pbbuttonsd.conf
> SleepKey = 116
> LCD_IllumUpKey = 225
> LCD_IllumDownKey = 224
> KBD_IllumUpKey = 230
> KBD_IllumDownKey = 229
> KBD_IllumOnKey = 228
> VolumeUpKey = 115
> VolumeDownKey = 114
> MuteKey = 113
> EjectCDKey = 161
> TPModeUpKey = 225 + alt
> TPModeDownKey = 224 + alt
>
> $ grep ^[^#] /etc/default/mouseemu
> RIGHT_CLICK="-right 0 125"
> MID_CLICK="-middle 0 126"
> SCROLL="-scroll 56"
>
> the mouseemu version installed on my system is:
> ii mouseemu 0.15-1 Emulate mouse buttons and mouse wheel
>
> cheers, piem
>
> -- System Information:
> Debian Release: 3.1
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: powerpc (ppc)
> Kernel: Linux 2.6.9-powerpc
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
>
> Versions of packages pbbuttonsd depends on:
> ii eject 2.0.13deb-8sarge2 ejects CDs and operates CD-Changer
> ii hdparm 5.9-4 tune hard disk parameters for high
> ii libasound2 1.0.8-3 ALSA library
> ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
>
> -- no debconf information
>
>

--
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~

On Wed, May 04, 2005 at 03:05:50PM +0200, Gaudenz Steinlin wrote:
> Hi
>
> On Fri, Apr 15, 2005 at 02:12:49AM +0100, Paul Brossier wrote:
> > Package: pbbuttonsd
> > Version: 0.6.7-1
> > Severity: normal
> >
> > I'm not sure which of the two causes problem. If i stop mouseemu, i can
> > access the pbbutonsd keys again. This happens with 0.6.6-3 and 0.6.7-1.
>
> I can't reproduce this with pbbuttonsd 0.6.6-3. For me pbbuttonsd keys
> don't stop working.

i can reproduce this with the default config of mouseemu.

> Does this only happen with mouseemu 0.15-2 or also with older
> versions?

it used to work less than a couple of months ago.

> Do all keys stop working or only some?

brightness and volume most importantly. the eject key isn't
working anyway.

> Does the order of starting pbbuttonsd and mouseemu matter?

no, it does not seem so.

> And why did you reassign this bug to mouseemu? There is no reason mentioned
> in the bug log. Please make sure that all relevant information is also in the
> bug log because I don't have access to private conversation between you and

we had no special private conversation with Frank, i just
mentionned the bug to him on irc. at the time i submitted it, i
was not sure which of the two should this bug be filed against.

but now i have another issue, which seem only related to
mouseemu: the [Super]+[Left,Right] combination which is used to
switch between ttys does not work when mouseemu runs.

bye, piem

> Frank.
>
> Gaudenz
>
> >
> > On my ibook i use the following settings:
> >
> > $ grep Key\ /etc/pbbuttonsd.conf
> > SleepKey = 116
> > LCD_IllumUpKey = 225
> > LCD_IllumDownKey = 224
> > KBD_IllumUpKey = 230
> > KBD_IllumDownKey = 229
> > KBD_IllumOnKey = 228
> > VolumeUpKey = 115
> > VolumeDownKey = 114
> > MuteKey = 113
> > EjectCDKey = 161
> > TPModeUpKey = 225 + alt
> > TPModeDownKey = 224 + alt
> >
> > $ grep ^[^#] /etc/default/mouseemu
> > RIGHT_CLICK="-right 0 125"
> > MID_CLICK="-middle 0 126"
> > SCROLL="-scroll 56"
> >
> > the mouseemu version installed on my system is:
> > ii mouseemu 0.15-1 Emulate mouse buttons and mouse wheel
> >
> > cheers, piem
> >
> > -- System Information:
> > Debian Release: 3.1
> > APT prefers unstable
> > APT policy: (500, 'unstable')
> > Architecture: powerpc (ppc)
> > Kernel: Linux 2.6.9-powerpc
> > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> >
> > Versions of packages pbbuttonsd depends on:
> > ii eject 2.0.13deb-8sarge2 ejects CDs and operates CD-Changer
> > ii hdparm 5.9-4 tune hard disk parameters for high
> > ii libasound2 1.0.8-3 ALSA library
> > ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
> >
> > -- no debconf information
> >
> >
>
> --
> Ever tried. Ever failed. No matter.
> Try again. Fail again. Fail better.
> ~ Samuel Beckett ~

Hi,

I can confirm this same behavior with an older version of pbbuttonsd
(0.6.3a). The problem only started after upgrading mouseemu from 0.12-1 to
0.15-2.

Order of starting mouseemu and pbbuttonsd does not matter. Starting
mouseemu 0.15-2 'steals' the function key events from pbbuttonsd, stopping
mouseemu 0.15-2 seems to pass them back (I haven't actually logged events
in pbbuttonsd; the brightness and volume adjust just starts working
again).

0.12-1 doesn't interfere at all (I just tried a locally compiled version)
but suffers from scrolling and pasting bugs. The code differences between
0.12-1 and 0.15-2 are quite extensive; I will start merging in changes
into 0.12-1 to see when it starts to break.

 Michael

Hi,

I found the reason for pbbuttonsd not getting any more key events:
mouseemu grabbing the device for exclusive use seems to prevent
other processes from receiving events ...

Line 232 of mouseemu.c:

 register_inputhandler(fd, keyboard_handler, 1);

Change that 1 to 0 and key events are passed on to pbbuttonsd (I imagine
the mouse register device call needs the same change to let pbbuttonsd
react to mouse moves).

Side effect: the 3~ crap on pasting with the mouse is back.

I've played a bit with the event passthrough mechanism (sending sync
events after passed key events) to no avail.

 Michael

On Thu, Jun 02, 2005 at 06:24:38PM +0200, Michael Schmitz wrote:
> Hi,
>
> I found the reason for pbbuttonsd not getting any more key events:
> mouseemu grabbing the device for exclusive use seems to prevent
> other processes from receiving events ...
>
> Line 232 of mouseemu.c:
>
> register_inputhandler(fd, keyboard_handler, 1);
>
> Change that 1 to 0 and key events are passed on to pbbuttonsd (I imagine
> the mouse register device call needs the same change to let pbbuttonsd
> react to mouse moves).

I have tested this and after restarting both mouseemu and pbbuttonsd, i
got the pbbuttonsd keys back. This seems to fix #307068 as well.

> Side effect: the 3~ crap on pasting with the mouse is back.
>
> I've played a bit with the event passthrough mechanism (sending sync
> events after passed key events) to no avail.

I don't know what sort of crap that could be. Copy paste seems to work
just fine from both the mouse and the keyboard here.

Paul

On Thu, Jun 02, 2005 at 07:06:08PM +0100, Paul Brossier wrote:
> On Thu, Jun 02, 2005 at 06:24:38PM +0200, Michael Schmitz wrote:
> > Hi,
> >
> > I found the reason for pbbuttonsd not getting any more key events:
> > mouseemu grabbing the device for exclusive use seems to prevent
> > other processes from receiving events ...
> >
> > Line 232 of mouseemu.c:
> >
> > register_inputhandler(fd, keyboard_handler, 1);
> >
> > Change that 1 to 0 and key events are passed on to pbbuttonsd (I imagine
> > the mouse register device call needs the same change to let pbbuttonsd
> > react to mouse moves).
>
> I have tested this and after restarting both mouseemu and pbbuttonsd, i
> got the pbbuttonsd keys back. This seems to fix #307068 as well.

pbbuttonsd must be started after mouseemu for this to work, and #307068
is still around: if a mouse was plugged at boot time, it's now
pbbuttonsd that eats all the cpu when the mouse gets unpplugged. but the
keyboard remains usable now, so it got much better already.

paul

> > Line 232 of mouseemu.c:
> >
> > register_inputhandler(fd, keyboard_handler, 1);
> >
> > Change that 1 to 0 and key events are passed on to pbbuttonsd (I imagine
> > the mouse register device call needs the same change to let pbbuttonsd
> > react to mouse moves).
>
> I have tested this and after restarting both mouseemu and pbbuttonsd, i
> got the pbbuttonsd keys back. This seems to fix #307068 as well.

I had to comment out the passthrough() call in the keyboard event handler
as well BTW. Otherwise keypresses would show up twice (on key release) in
the shell. Didn't happen every time though.

> > Side effect: the 3~ crap on pasting with the mouse is back.
> >
> > I've played a bit with the event passthrough mechanism (sending sync
> > events after passed key events) to no avail.
>
> I don't know what sort of crap that could be. Copy paste seems to work
> just fine from both the mouse and the keyboard here.

That's the ordinary F11 keysym being received by the terminal app. I
could solve that by hacking the X keymap. I'd rather have the option to
_not_ send a button and a key event on F11 (that's what happens with
mouseemu grabbing the events: the key event is translated into a button
event, and only that one is sent). So we'd explicitly need to delete the
key event from the event queue here. No idea how to do that. No idea why
passing the brightness button events through to pbbuttonsd doesn't work,
either (are there raw as opposed to cooked events?).

 Michael

> > > Change that 1 to 0 and key events are passed on to pbbuttonsd (I imagine
> > > the mouse register device call needs the same change to let pbbuttonsd
> > > react to mouse moves).
> >
> > I have tested this and after restarting both mouseemu and pbbuttonsd, i
> > got the pbbuttonsd keys back. This seems to fix #307068 as well.
>
> pbbuttonsd must be started after mouseemu for this to work, and #307068

Doesn't matter in my setup - I can start mouseemu manually way after
bootup and pbbuttonsd still receives its events.

> is still around: if a mouse was plugged at boot time, it's now
> pbbuttonsd that eats all the cpu when the mouse gets unpplugged. but the
> keyboard remains usable now, so it got much better already.

I can't confirm this one. Kernel 2.6.11 (bitkeeper from around early
March) here.

 Michael

> > > Change that 1 to 0 and key events are passed on to pbbuttonsd (I imagine
> > > the mouse register device call needs the same change to let pbbuttonsd
> > > react to mouse moves).
> >
> > I have tested this and after restarting both mouseemu and pbbuttonsd, i
> > got the pbbuttonsd keys back. This seems to fix #307068 as well.
>
> pbbuttonsd must be started after mouseemu for this to work, and #307068

Paul,

Do you use devfs/devfsd? Otherwise, please look at /dev/input to see how
many event%d devices you have. My setup had only four event devices which
were just enough for the builtin devices ... took me a while and evbug to
figure out just how many devices were in the game, and what device the
passthrough events came from.

pbbuttonsd relies on special files present in /dev/input (or devfsd making
them up on the fly) to scan for keyboard devices. In my case, the
specials for the virtual (uinput) devices weren't present, so the devices
were never registered.

With this change, and mouseemu (original 0.15) started before pbbuttonsd
(original 0.6.6 with some syslog() crap added) I get normal behavior of
both tools. When you start mouseemu after pbbuttonsd you may need to do a
/etc/init.d/mouseemu reload which rescans the event devices.

One minor nit with pbbuttonsd remains: stopping and restarting pbbuttonsd
loses all visual feedback for event response until the next login. Must
be X related.

 Michael

Hi Miachel

Many thanks for your investigation on this bug! I hope to find some
time over the next week-end to fix this bug.

On Thu, Jun 02, 2005 at 06:24:38PM +0200, Michael Schmitz wrote:
> Hi,
>
> I found the reason for pbbuttonsd not getting any more key events:
> mouseemu grabbing the device for exclusive use seems to prevent
> other processes from receiving events ...
>
> Line 232 of mouseemu.c:
>
> register_inputhandler(fd, keyboard_handler, 1);
>
> Change that 1 to 0 and key events are passed on to pbbuttonsd (I imagine
> the mouse register device call needs the same change to let pbbuttonsd
> react to mouse moves).

OK this sounds very plausible. I also found out, that restarting
pbbuttonsd gets back the keys (even with mouseemu 0.15-2).
>
> Side effect: the 3~ crap on pasting with the mouse is back.
>
> I've played a bit with the event passthrough mechanism (sending sync
> events after passed key events) to no avail.

This is not optimal. The initial reason for all these changes was to
avoid this crap. It's quite annoing.

Gaudenz

--
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~

On Fri, Jun 03, 2005 at 10:07:02AM +0200, Michael Schmitz wrote:
> > > > Change that 1 to 0 and key events are passed on to pbbuttonsd (I imagine
> > > > the mouse register device call needs the same change to let pbbuttonsd
> > > > react to mouse moves).
> > >
> > > I have tested this and after restarting both mouseemu and pbbuttonsd, i
> > > got the pbbuttonsd keys back. This seems to fix #307068 as well.
> >
> > pbbuttonsd must be started after mouseemu for this to work, and #307068
>
> Doesn't matter in my setup - I can start mouseemu manually way after
> bootup and pbbuttonsd still receives its events.

i guess the fact my mouseemu configuration uses the fn makes a
difference here.

paul

> > > pbbuttonsd must be started after mouseemu for this to work, and #307068
> >
> > Doesn't matter in my setup - I can start mouseemu manually way after
> > bootup and pbbuttonsd still receives its events.
>
> i guess the fact my mouseemu configuration uses the fn makes a
> difference here.

If pbbuttonsd does the "fnkeysfirst" setting, then yes. Anything on the
/dev/input/event* idea?

 Michael

On Mon, Jun 06, 2005 at 03:50:59PM +0200, Michael Schmitz wrote:
> > > > pbbuttonsd must be started after mouseemu for this to work, and #307068
> > >
> > > Doesn't matter in my setup - I can start mouseemu manually way after
> > > bootup and pbbuttonsd still receives its events.
> >
> > i guess the fact my mouseemu configuration uses the fn makes a
> > difference here.
>
> If pbbuttonsd does the "fnkeysfirst" setting, then yes. Anything on the
> /dev/input/event* idea?

i indeed have this line in my /etc/pbbuttonsd.conf:

KBDMode = fkeysfirst

well, you mentionned devfsd, i use udev instead. here is what i have:

$ ll /dev/input/event*
crw-rw---- 1 root root 13, 64 2005-06-06 13:31 /dev/input/event0
crw-rw---- 1 root root 13, 65 2005-06-06 13:31 /dev/input/event1
crw-rw---- 1 root root 13, 66 2005-06-06 13:31 /dev/input/event2
crw-rw---- 1 root root 13, 67 2005-06-06 13:31 /dev/input/event3
crw-rw---- 1 root root 13, 68 2005-06-06 13:31 /dev/input/event4
crw-rw---- 1 root root 13, 69 2005-06-06 13:32 /dev/input/event5
crw-rw---- 1 root root 13, 70 2005-06-06 13:32 /dev/input/event6

cheers, paul

Just for the record if someone wants to work on these bugs. My old
Powerbook was stolen and I currently don't have access to a
powerbook/ibook to fix these bugs. So feel free to NMU if you have a fix
for any of these bugs until further notice.

Gaudenz

--
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~

I can not fix and / or reproduce this bug but I'd like to add that the
bug has been fixed in Ubuntu:
https://launchpad.net/ubuntu/+source/mouseemu/+bug/67954

Martin

Hi Gaudenz,

Please apply the bustype_virtual.dpatch patch from Ubuntu (bug #67954,
already mentionned), it'll help a lot for the bug you just reported
against pommed ;)

Thanks,

JB.

--
 Julien BLACHE - Debian & GNU/Linux Developer - <email address hidden>

 Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169

Source: mouseemu
Source-Version: 0.15-7

We believe that the bug you reported is fixed in the latest version of
mouseemu, which is due to be installed in the Debian FTP archive:

mouseemu_0.15-7.diff.gz
  to pool/main/m/mouseemu/mouseemu_0.15-7.diff.gz
mouseemu_0.15-7.dsc
  to pool/main/m/mouseemu/mouseemu_0.15-7.dsc
mouseemu_0.15-7_powerpc.deb
  to pool/main/m/mouseemu/mouseemu_0.15-7_powerpc.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Gaudenz Steinlin <email address hidden> (supplier of updated mouseemu package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 29 Apr 2007 17:53:10 +0200
Source: mouseemu
Binary: mouseemu
Architecture: source powerpc
Version: 0.15-7
Distribution: unstable
Urgency: low
Maintainer: Gaudenz Steinlin <email address hidden>
Changed-By: Gaudenz Steinlin <email address hidden>
Description:
 mouseemu - Emulate mouse buttons and mouse wheel
Closes: 304734 407725
Changes:
 mouseemu (0.15-7) unstable; urgency=low
 .
   * The "The hard work was done by Ubuntu" release
   * debian/patches/bustype_virtual.dpatch: Use new BUS_VIRTUAL bus type for
     our uinput devices (Closes: 304734). Thanks to Colin Watson and Ubuntu for
     this patch.
   * debian/patches/dual_devices.dpatch: Handle input devices that provide
     both keyboard and mouse events. Thanks to Colin Watson for the patch.
     (Closes: 407725)
   * update debian/patches/61_rescan.dpatch: Block SIGHUP and SIGALRM in the
     parent. Fix rescan_devs not to skip every other input handler. Taken from
     Ubuntu.
   * update debian/patches/41_defaults.dpatch, debian/control, debian/rules,
     debian/patches/51_manpage: Enable Mouse Button Emulation by Default on
     Intel Macs. Use dmidecode to detect Intel Macs. Code taken from Ubuntu.
Files:
 331a2a428cfddd42a40ebdd00ec8f276 934 utils optional mouseemu_0.15-7.dsc
 68f1b78e58e5060739b2bcc408a4c71b 13478 utils optional mouseemu_0.15-7.diff.gz
 894a7ded557302e8f4a91c9f3116400c 15472 utils optional mouseemu_0.15-7_powerpc.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBRjktqU0yN7tZsYcyAQJfqQf/XnaB0t9FOfDVgAIpythrqyzfaSAZp2lr
anJjj2or72hWq/tKtQayMDl7PkPAIvTK8uQPr/TaJtTsrFv1fiSgPFADishfrpIc
3XgOWeTU9MdRTnw2gv9KobLUAi2sYcvLFPtkmT0/dcngZynP8VlrE07M1MCR6Mue
lLGNAoEjur6Yx4eTUDkeanWcEUwqzmEayvQ5X3Tr4sRWtOLMcbPTdsKiBhe/qhtG
/v9ZSRY3zCJCJSEubvIvqJW9f5zKnm5XOHGjXqKpYb+UvSDa0IJWWHDiezA1ZS+a
tgj01e7Zg4uAK7d+Lq/TlZeqfCXKl9Vz09OSMjw7pSdHBzl3oDTCeg==
=gKrX
-----END PGP SIGNATURE-----