Multimedia key partially working

[Yang Zhao]

Binary package hint: gnome-control-center

I have a Logitech LX700 wireless keyboard/mouse bundle. I have set keyboard model to "Logitech Cordless Desktop Pro" in Keyboard preferences, and some multimedia keys are recognized in "Preference->keyboard shortcuts". It can read the XF86AudioMute, XF86AudioLowerVolume, XF86RaiseVolume, XF86AudioPlay keys and a bunch of others. Only 3 of them actually works - nothing happens when I try to raise the volume through the keyboard. The other 3 keys however works perfectly.

I'm running edgy, and is up to date when I report this bug (Sep 07 2006)

[Sndirsch-suse (sndirsch-suse)]

Created an attachment (id=5787)
inet_logitech_base_xf86audioraisevolume.diff

[Sndirsch-suse (sndirsch-suse)]

Created an attachment (id=5788)
rules_logi_typo.diff

description fix. On SUSE SaX2 uses the wrong keyboard for configuration
("logiink" instead of "logicink") because of this typo.

[Sergey V. Udaltsov (svu)]

Stefan, having two keys for the same symbol is not a problem - both definitions
should work ok. The real bug is with the code which is binding these definitions
to keycodes - it should be aware that one symbol can be bound to different
keycodes. From X and XKB POV it is perfectly legal configuration IMHO.
I would prefer just to leave it as it is now.
But wrong identifier is a realy bug, so I'll fix it ASAP.

[Sergey V. Udaltsov (svu)]

The ID bug is fixed, thanks. The rest I'd consider as INVALID or NOTOURBUG...

[Denis Barbier (barbier)]

(In comment #3)
> Stefan, having two keys for the same symbol is not a problem

Sergey, we had a similar report in Debian BTS http://bugs.debian.org/363925
Bug submitter tells that his key does not work with GNOME when there are
such duplicates. I do not have GNOME installed at the moment, this is why
I did not investigate it yet.

[Sergey V. Udaltsov (svu)]

As I said - it looks like a problem with GNOME. It goes nuts trying to map the
symbol name to keycode - it just does not take into account the fact that this
mapping may be a vector...

[Sndirsch-suse (sndirsch-suse)]

Thanks!

[L-lunak (l-lunak)]

I disagree with comment #3. First of all it is just plain against common sense
to write code to handle possible mapping of one keysym to several keycodes just
because of weird cases like this, and secondly it's not possible (Xlib manual
section 16.1 or just the manpage):

KeyCode XKeysymToKeycode(Display *display, KeySym keysym);

The function prototype makes it obvious that from X POV it is not legal to have
one keysym mapped to several keycodes. Please fix the keymap.

[Ryan Reich (ryan-reich)]

*** Bug 7277 has been marked as a duplicate of this bug. ***

[Sergey V. Udaltsov (svu)]

> I disagree with comment #3. First of all it is just plain against common sense
Is it? What is people what two keys perform absolutely same action, regardless
of the application?

> because of weird cases like this, and secondly it's not possible (Xlib manual
> section 16.1 or just the manpage):
OK, this is the killer argument. Funny but neither XKB internal structures nor
file formats prevent from having multiple keycodes per keysym. It is only in
core X11 where this causes the conflict. Anyway, you nearly convinced me. I will
have a look around, see if I find any clarifications on this ambiguity between X
and XKB - and most probably will do something about it.

[Sergey V. Udaltsov (svu)]

There is an interesting message from Danilo Segan on XKB maillist, which I cite
here (as he asked):
---------------------------------------------
> > because of weird cases like this, and secondly it's not possible
> (Xlib manual
> > section 16.1 or just the manpage):
(reinserted the prototype)
> >
> > KeyCode XKeysymToKeycode(Display *display, KeySym keysym);
> >
> OK, this is the killer argument. Funny but neither XKB internal
> structures nor
> file formats prevent from having multiple keycodes per keysym. It is
> only in
> core X11 where this causes the conflict. Anyway, you nearly convinced
> me. I will
> have a look around, see if I find any clarifications on this ambiguity
> between X
> and XKB - and most probably will do something about it.

Not really—if the prototype was actually reverse:

  KeySym XKeycodeToKeysym(Display *display, KeyCode keycode);

then this would be the case. Algebraic definition of the function
allows for having more than one value mapped to a single value.

And the man page actually supports your initial comment with a different
function for reverse mapping:

      KeySym XKeycodeToKeysym(Display *display, KeyCode keycode, int
index);

where index "Specifies the element of KeyCode vector." (so, it is
expected to have more than one).

So, no, it's not a bug in xkeyboard-config.
---------------------------------------------

[Sergey V. Udaltsov (svu)]

Danilo, I think it is still a bug. You see, the question here is whether we can
have, say KC1 and KC2 mapped to KS1 (two keycodes mapped to one keysym). The
function XKeysymToKeycode can only return one keycode for the keysym (say, KC1
for KS1) - so there is no place for KC2 in this API.

[Sergey V. Udaltsov (svu)]

Danilo agreed :)

[L-lunak (l-lunak)]

Re: comment #11:
You misunderstand. If an app is supposed to react e.g. on XF86VolumeUp, then it
needs to do a global grab. But XGrabKey() needs a keycode. However
XKeySymToKeyCode() only returns one keycode for the keysym, so it's possible to
grab only one of the two keys.

Moreover the index in XKeycodeToKeysym() has nothing to do with mapping one
keysym to two keycodes. It's the index which specifies which keysym for a
particular keycode should be selected according to group and lock modifiers, as
explained in Xlib reference section 12.7.

[Sergey V. Udaltsov (svu)]

Fixed in CVS

[Yang Zhao (zhyang11)]

Binary package hint: gnome-control-center

I have a Logitech LX700 wireless keyboard/mouse bundle. I have set keyboard model to "Logitech Cordless Desktop Pro" in Keyboard preferences, and some multimedia keys are recognized in "Preference->keyboard shortcuts". It can read the XF86AudioMute, XF86AudioLowerVolume, XF86RaiseVolume, XF86AudioPlay keys and a bunch of others. Only 3 of them actually works - nothing happens when I try to raise the volume through the keyboard. The other 3 keys however works perfectly.

I'm running edgy, and is up to date when I report this bug (Sep 07 2006)

[Denis Barbier (barbier)]

*** Bug 8282 has been marked as a duplicate of this bug. ***

[Sebastien Bacher (seb128)]

Thanks for your bug. If you use the keyboard shortcut dialog and assign that action to the volume up key again, does the key label change? does it work then? what value do you have for the key event if you use xev?

[Yang Zhao (zhyang11)]

The key was recognized correctly in the keyboard shortcut window. I can change it to some other key and then change it back to XF86AudioRaiseVolume . xev gives a reasonable response:
KeyPress event, serial 29, synthetic NO, window 0x2800001,
    root 0x136, subw 0x0, time 3288983755, (340,256), root:(1623,298),
    state 0x10, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XKeysymToKeycode returns keycode: 175
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x2800001,
    root 0x136, subw 0x0, time 3288983755, (340,256), root:(1623,298),
    state 0x10, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XKeysymToKeycode returns keycode: 175
    XLookupString gives 0 bytes:
    XFilterEvent returns: False
it's not a actual key on the keyboard, but a small disk you can rotate. In one direction it gives XF86AudioLowerVolume, on the other it gives XF86RaiseVolume event. The program that actually does the job of adjusting volume somehow failed to recognize this key.

----- Original Message ----
From: Sebastien Bacher <email address hidden>
To: <email address hidden>
Sent: Monday, September 18, 2006 11:41:23 AM
Subject: [Bug 59429] Re: Multimedia key partially working

Thanks for your bug. If you use the keyboard shortcut dialog and assign
that action to the volume up key again, does the key label change? does
it work then? what value do you have for the key event if you use xev?

** Changed in: control-center (Ubuntu)
   Importance: Untriaged => Low
     Assignee: (unassigned) => Ubuntu Desktop Bugs
       Status: Unconfirmed => Needs Info

--
Multimedia key partially working
https://launchpad.net/bugs/59429

[Sebastien Bacher (seb128)]

thank you for the details, reopening, if somebody understand how multimedia keyboard are supposed to work feel free to commen

[tequila34fr (omarty)]

I had the same problem and find this workaround (with Google help...) by commenting out the line beginning with :
" key <I2F> { [ XF86AudioRaiseVolume ] };"

in /etc/X11/xkb/symbols/inet, logitech_base section :

example :
--------------------------------------------------------------

partial hidden alphanumeric_keys
xkb_symbols "logitech_base" {

    key <I01> { [ XF86AudioMedia ] };
    key <I02> { [ XF86WWW ] };
    key <I10> { [ XF86AudioPrev ] };
......
    key <I22> { [ XF86AudioPlay, XF86AudioPause ] };
    key <I24> { [ XF86AudioStop ] };
    key <I2E> { [ XF86AudioLowerVolume ] };
// key <I2F> { [ XF86AudioRaiseVolume ] };
    key <I30> { [ XF86AudioRaiseVolume ] };
    key <I32> { [ XF86HomePage ] };
    key <I3B> { [ XF86New ] };
......
};

--------------------------------------------------------------
After a X11 restart, everything is fine.
The same problem occurs in dapper and edgy.

It seems there is two keys defined for the same action... I2F and I30...

[Yang Zhao (zhyang11)]

This fixes the problem. However it's interesting to note that it takes me about 31 steps to go from mute to full volume, but only 12 steps to reduce to mute. The 2 keys change volume in different amount.

----- Original Message ----
From: tequila34fr <email address hidden>
To: <email address hidden>
Sent: Sunday, October 1, 2006 4:25:04 PM
Subject: [Bug 59429] Re: Multimedia key partially working

I had the same problem and find this workaround (with Google help...) by commenting out the line beginning with :
" key <I2F> { [ XF86AudioRaiseVolume ] };"

in /etc/X11/xkb/symbols/inet, logitech_base section :

example :
--------------------------------------------------------------

partial hidden alphanumeric_keys
xkb_symbols "logitech_base" {

    key <I01> { [ XF86AudioMedia ] };
    key <I02> { [ XF86WWW ] };
    key <I10> { [ XF86AudioPrev ] };
......
    key <I22> { [ XF86AudioPlay, XF86AudioPause ] };
    key <I24> { [ XF86AudioStop ] };
    key <I2E> { [ XF86AudioLowerVolume ] };
// key <I2F> { [ XF86AudioRaiseVolume ] };
    key <I30> { [ XF86AudioRaiseVolume ] };
    key <I32> { [ XF86HomePage ] };
    key <I3B> { [ XF86New ] };
......
};

--------------------------------------------------------------
After a X11 restart, everything is fine.
The same problem occurs in dapper and edgy.

It seems there is two keys defined for the same action... I2F and I30...

--
Multimedia key partially working
https://launchpad.net/bugs/59429

[Sebastien Bacher (seb128)]

That was a xkeyboard-config problem and fixed with the current package

[Sebastien Bacher (seb128)]

Note that the volume steps which are different is an another question and considered as a feature