Darren Kenny-san wrote (06/30/08 06:20 PM):
> Brian Cameron wrote:
>> Brian:
>>
>>  > The IIIMF applet is already in OpenSolaris and though it doesn't
>>  > appear to link xklavier, it's keyboard layout tab says:
>>  >
>>  >  "Use autodetect (does not work in remote environment)"
>>  >
>>
>> The keyboard switcher applet uses xmodmap if libxklavier is not
>> available, so I would bet it is building with this configuration.
> 
> I believe that IIIMF uses the XKB Extension, but it is only run when the 
> user's
> locale supports switching (e.g. it's not run with using C or iso8859-15), but 
> it
> is if the user runs a UTF-8 based locale.

AFAIK, IIIMF uses ioctl(2) to get the console keyboard.
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/kbd/kbd.c#get_layout

My understanding is most of the functionalities of KeyboardLayoutSwitcher are 
available with IIIMF at present.

Thanks,
fujiwara

> 
> The reason for the inability to auto-detect is more down to access to the
> keyboard hardware which provides it's layout (at least with USB), but even at
> that I'm sure there are problems - e.g. on Macbooks the layout is very 
> different
> to most PC type keyboards, even though it's meant to be an ISO standard, which
> doesn't appear to be supported all that well even in XKB.
> 
>> The xmodmap interfaces are also not standard across different
>> Xservers, so you can have the same sorts of problems using it
>> in this mode as with using libxklavier.
> 
> Yes, xmodmap is a problem, and it's the no. 1 reason that we don't use it on
> Solaris since by default on Sparc systems using Xsun the preferred and more
> consistent XKB extension is off by default.
> 
> I think if we had Xsun enable XKB by default we could start using the existing
> GNOME keyboard applets and associated code/libs if we wish.
> 
>>>  Does iiim also rely on private X APIs?  What is the relationship 
>>> between IIIM and KeyboardLayoutSwitcher applet?   Would 
>>> KeyboardLayoutSwitcher provide redundant functionality which is already 
>>> provided by IIIM?   I think a keyboard switcher would be very useful, 
>>> (the fact that we got so many trouble calls on odd combinations of 
>>> keyboards and Xservers tells me that many people were using it!)
> 
> There does appear to be overlap, but I'll be honest in admitting I've not had
> much need for either in the past, but now using my MacBook as my main platform
> I'm finding more keyboard issues due to Mac's layout being so different and 
> not
> as well supported in Xorg's XKB mappings as PC keyboards - so plugging in
> different USB keyboards results in more miss-mapped keys than before when 
> using
> a PC style laptop.
> 
> I think that this type of keyboard layout selection is not handled by IIIM 
> which
> is most focused on locale layout changes.
> 
>> I'm not very familiar with IIIM.  I'd bet if you asked Takao, that
>> he could provide some perspective here.
> 
> I'm sure that the Takao and his team would be best placed to comment on 
> this...
> 
>>> I wonder if it is possible to do this in a supportable way and provide 
>>> an interface at least as intuitive as what Sun and Apple had years ago 
>>> (e.g. Solaris 7): http://docs.sun.com/app/docs/doc/805-4123/6j3tmpc73?a=view
>> I suspect it would be, but there's probably not an easy, quick solution.
>> To do this properly, this would likely be a cross-consolidation project.
>> Therefore, it would likely require a high enough priority to get some
>> commitment from the different teams that would need to be involved.  Or
>> perhaps the open source community will solve this problem in the
>> meantime.
> 
> I think we have a choice - either enhance IIIM to always run and support
> changing of varied layouts (many of which are already described for XKB) in 
> each
> locale (e.g. MacBook, PC, etc.), or port the existing GNOME stack - but I 
> have a
> feeling that this also depends on HAL work for identifying the keyboards 
> (based
> on observations on the patches sent to the HAL mailing list for such things).
> 
> Thanks,
> 
> Darren.
> 


Reply via email to