Created attachment 11312 [details] [review]
updates from input.h

Could you please merge it with the last commit?

Looking at the conflict, this isn’t a no-brainer.

First, (and I didn’t notice it either when I read the commit mail) he used keycodes 241 to 245 w/o noticing that X’s keycodes are offset from linux’s by +8.  So those were already assigned in that file to the FORWARDMAIL, SAVE, DOCUMENTS and BATTERY keys.  If you add 8 to those to fix that oversight, they exactly overlap the new ACPI keycodes VIDEO_NEXT, VIDEO_PREV, BRIGHTNESS_CYCLE, BRIGHTNESS_ZERO and DISPLAY_OFF, all of which are likely to be seen in the real world.

Unless the keycodes can be larger than 8 bits, I don’t think there is room for the virtuals.

Also, evdev works for me w/o them.  

Only inet(apple), inet(logitech_g15) and pc(pc105) have <MDSW>, and only pc(pc105) has the other 5 symbols.  Perhaps the real fix for his problem is there?

(My setxkbmap -print output (ignoring groups 2 thru 4) looks like:

xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete+ledscroll(group_lock)"	};
	xkb_symbols   { include "pc+us(altgr-intl)+inet(evdev)+altwin(super_win)+group(ctrls_toggle)+ctrl(nocaps)+compose(menu)"	};
	xkb_geometry  { include "latitude"	};
};

Perhaps the altwin(super_win) makes the difference in his and my experiences?

I don’t know how you want to deal with this.

Maybe the 5 virtuals could be stuck below <ESC>?  0 thru 8 are all unspoken for.

Created attachment 11318 [details] [review]
merged updates from input.h

In case changing the minimum keycode from 8 to 1 and putting the virtuals down there is OK, here is a patch to do that and add in the new codes from linux/input.h

I do not know any way to make keycodes > 256. So, let's put virtual keys into 1-6 region and see whether we get any complaints. I do not think the will.

Anyway, it is now committed, thanks!

xkbcomp chokes on this:

 Error: Illegal keycode 1 (must be in the range 8-255 inclusive)

Does this patch require an updated version of xkbcomp too?

(In reply to comment #6)
> xkbcomp chokes on this:
> 
>  Error: Illegal keycode 1 (must be in the range 8-255 inclusive)
> 
> Does this patch require an updated version of xkbcomp too?

Ping?

Sorry, I forgot to look at it. No, there was no xkbcomp patching. It seems it does not like "low" keycodes. I'll have a look at the source and try to realize why. But I think we're better of not using these codes - let's move these fake keys above 8.

James, don't you mind moving them?

I found several not used keycodes and assigned fake keys to them. Bernardo, coul you please check?

I’ve been out of touch for a bit....

The minkeycode is set to 8 in XKB.h in kbproto.  And I’ve not figured out why.

Certainly several apps — including the x server — would need a recompile were it changed.

Since there were some unused ones, though, that looks to be a better solution.

(In reply to comment #11)

> The minkeycode is set to 8 in XKB.h in kbproto.  And I’ve not figured out
> why.
>
> Certainly several apps — including the x server — would need a recompile
> were it changed.

I think I know.  In the X11 wire protocol, the first 8 keycodes are
reserved for the hardcoded (pre-xkb) modifier keys.

This is why all keysyms in evdev are offset by 8 with respect to
the kernel codes.

By the way, this explanation should really go on top of the file,
because I wasted a lot of time trying to figure it out, and if
it wasn't for Zephaniah, I'd never have ;-)