Created attachment 5787 [details] [review]
inet_logitech_base_xf86audioraisevolume.diff

Created attachment 5788 [details] [review]
rules_logi_typo.diff

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

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.

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

(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.

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...

Thanks!

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.

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

> 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.

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.
---------------------------------------------

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.

Danilo agreed :)

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.

Fixed in CVS

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