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