Keysym additions.
Jim Gettys
jg at laptop.org
Thu Sep 21 12:52:28 PDT 2006
On Thu, 2006-09-21 at 22:24 +0300, Daniel Stone wrote:
> On Thu, Sep 21, 2006 at 03:12:51PM -0400, Jim Gettys wrote:
> > On Thu, 2006-09-21 at 21:28 +0300, Daniel Stone wrote:
> > > On Thu, Sep 21, 2006 at 01:57:34PM -0400, Jim Gettys wrote:
> > > > 2) Should we continue in the XF86 name space for additional X.org
> > > > keysyms: I think not; that way we can't have collisions with XFree's
> > > > allocations.
> > >
> > > Presumably the names are tied to DDX rather than vendor, which could
> > > easily make it either. The worst they can do is to add non-colliding
> > > keysyms. There's no way they can add keysyms that conflict with what we
> > > have now.
> >
> > The point is if we add to the keysym list in the range of keysyms that
> > were defined XF86, we could collide.
>
> Right, but I don't see how XFree86 are in a position to add keysyms that
> collide with the range we specify.
We're not; I'm saying we stay out of the XF86 address range and name
space where we (when many of us were working as part of XFree86) were
defining multimedia keys.
>
> If you really want, we could start using XOXK_foo, but then you're still
> going to have collisions as you're within the vendor-defined range, no?
>
> > > > a) XK_F1_5 through XK_F34_5, as intermediate keysyms for the F1-F35
> > > > range
> > >
> > > That's ... a lot of keysyms. Could you not use modifiers for this?
> >
> > They aren't modifiers. They are bona-fide keys.
>
> Ah, 0.5. So you have seventy function keys, or?
Actually, we have F1-F12, in 3 groups. But the X keysym list has F1-35.
So I was being
>
> > > > b) XK_FuncGroup1 - XK_FuncGroup5 (5 sets of function keys)
> > >
> > > Can you elaborate? Do you have one row of function keys, and these are
> > > essentially modifiers that shift the function number?
> >
> > We have a rubber keyboard; groups of function keys will be together as
> > sets, with little nubbins on top for the individual keys themselves.
> >
> > We don't want to always have to present 12 function keys to 5
> > year-olds....
>
> So you'll be able to press either the overarching Fx-F(x+3) button, or
> the individual button?
Yes. So the F1-F4 keys will also have a keysym XK_FuncGroup1 in
addition to F1-F4.
>
> > > > XK_Frame /* we have a notion of a "frame" in our UI */
> > >
> > > Can you elaborate on this?
> >
> > It makes a frame visible around the UI window (we're doing one
> > application at a time, again for simplicy). There are various icons in
> > the frame to access other activities.
>
> XF86XK_TaskPane, maybe?
Sure. I'm easy.
>
> > > > XK_Grab_L /* when grabbing things like maps to scroll them around */
> > > > XK_Grab_R /* when grabbing things like maps to scroll them around */
> > >
> > > Can you not use pointer keys to simulate a mouse button?
> >
> > I'm not sure what you mean.
>
> XKB supports 'pointer keys'. Unless I'm very much mistaken, you can
> simulate button presses, so would you not be able to use the Grab keys
> to generate a button press, and have it locking? That would presumably
> give you the desired 'grab' behaviour, unless your grabbing UI is
> something different from the usual 'press a mouse button and start
> moving the mouse'.
Think of panning around on a Google map, and you'll have the idea.
>
> > > > d) We also plan to have the fn key generate a keycode, rather than being
> > > > entirely silent; it turns out I could not find a definition for it:
> > > >
> > > > XK_Fn /* keysym if the Fn key is kind enough to send a code */
> > >
> > > I assume this is yet another modifier. Maybe take Hyper?
> >
> > Hyper is usually mapped to the Microsoft Windows key.
> >
> > I'm referring to the (typically labeled blue) Fn key you find on
> > keyboards that let you synthesize other keys. Rather than it being
> > entirely dead to the window system, we see no reason to not allow it to
> > be a fully fledged key and usable in other ways.
>
> Right, I'm aware of the Fn key. But given that its behaviour is that of
> a modifier, it would presumably be best to find and steal a modifier
> before adding our own.
No, Fn is not a modifier in the conventional sense at all; it causes a
keyboard to send different scan-codes entirely; on a laptop, that's how
you get to many of the keys that were on PC-105 keyboards.
> Bear in mind that this would be a special case
> for OLPC as no-one else that I'm aware of sends Fn; they all do it in
> hardware.
We'll do it in hardware as well; the difference is just you'll also get
a key event when the Fn key is pressed.
>
> > > > If we don't want to add such a plethora of mode switches to the list,
> > > > I'd suggest just
> > > >
> > > > XK_Language_switch_1
> > > > XK_Language_switch_2
> > >
> > > Could you not use XK_Mode_switch and have the language smarts in
> > > userspace?
> >
> > Maybe: I'm not enough of a keyboard guru to know exactly the semantics
> > of Mode_switch.
> >
> > And we have two of these keys.
>
> Well, the comment next to mode switch says 'character set switch'. ;)
>
> We could probably add another, though.
If people who understand input methods agree, that sounds sane.
Or maybe both such keys should have Mode_switch defined in addition to a
keysym distinguishing the two keys.
>
> Cheers,
> Daniel
Regards,
- Jim
--
Jim Gettys
One Laptop Per Child
More information about the xorg
mailing list