Folks:
The student application period has now closed. We got
12 applications total, exactly double what we got last year.
More importantly, we've got some really high quality ones in
different areas of the system. Given GSoC's primary goal of
creating new contributors, I'm particularly happ
as i mentioned before, these definitions are puzzling:
Kleft= KF|0x11,
Kright= KF|0x12,
these overlap with f11 and f12. since f11-f24 are all defined,
wouldn't it make more sense to move Kleft, etc. out of the way?
- erik
this is hexadecimal. KF|1 .. KF|0xC -> F1 .. F12.
not sure tho about F13-F24. never seen a keyboard
like that.
--
cinap
example: apple USB full sized kbd. f13 doesn't work. it has up to f18 USB
does define these keys.
cinap_len...@felloff.net wrote:
>this is hexadecimal. KF|1 .. KF|0xC -> F1 .. F12.
>not sure tho about F13-F24. never seen a keyboard
>like that.
>
>--
>cinap
>
>
also, i mix up kbd.c with /sys/include/keyboard.h. sorry.
why keyboard.h uses hex is beyond me. nobody ever says
press the f0xa key.
kbd.c has the more sensible
Home= KF|13, /* failure of vision; collides with f
keys */
Up= KF|14,
Pgup=
On 22 March 2014 20:03, erik quanstrom wrote:
>
> Kleft= KF|0x11,
> Kright= KF|0x12,
I suspect it was meant to describe a new internal sequence of values in the
0x1x range, which wasn't thought to be used.
> I suspect it was meant to describe a new internal sequence of values in the
> 0x1x range, which wasn't thought to be used.
i ment the question in terms of how to we fix it in a coordinated way.
it's not just the f keys, but there are other keys that are common these
days that seem useful.
- e
