Re: XKB Patch

On Fri, 15 May 2009, Marc-André Moreau wrote:

> 1) Re-using the numbers you have said, we currently have about 40 
> keymaps on a total of 120 possible keymaps that would constitute a 
> complete set of keymaps. 40 is still one third of 120, so we're not even 
> halfway done in order to bring full support for every keyboard layout.

True if you are just looking at the number or languages, but if you 
instead look at which countries and users that are actually using 
rdesktop, I would say that, in practice, we are covering almost all users 
and territories. We don't hear complains about missing keymaps from 2/3 of 
our users, right?


> I understand that if we go on a case by case basis, adding keymaps for 
> whatever keyboard layout someone needs, it does not require much effort. 
> The problem is that not everybody using an unsupported keyboard layout 
> would bother submitting a bug report, or getting to know rdesktop better 
> in order to write a new keymap and then submit it. Less common keyboard 
> layouts are most likely to remain unsupported. Also, even if the 
> majority of the keymaps currently work well, it may happen that someone 
> finds a bug in it and again it is no big deal to fix it. However, this 
> work of adding keymaps and maintaining them on an on-demand basis as 
> people find that their keyboard layout is unsupported or broken could be 
> solved using a "one for all" solution. That's why I thought of XKB, 
> because they already take care of doing that job.

I agree, in principle it's better if we can avoid having "our own" 
keymaps. I'm just concerned that this will in practice be very 
complicated. But I would be happy if you could prove that I'm wrong.


> You have mentioned that XKB has a lot of bugs. I have taken a look at the bug reports for xkb:
> https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=xke
> yboard-config&content=
> 
> And most of the bugs submitted are minor or cover aspects of the data base that we wouldn't even be using (such as
> the symbolic key name to keysym translation). Also, if we bother doing the maintenance work for our own set of
> keymaps, it would take just as much efforts to submit a bug report to XKB instead, and fix it on our side. We would
> benefit from that, and XKB would benefit from us (if we find bugs in their database).

Yes, squashing bugs in the upstream XKB database is better than fixing our 
own keymaps, I agree, if we are just talking about the XKB data base.

However, if we are talking about using the runtime XKEYBOARD extension as 
well, like Ilya Konstantinov suggests, we might suffer from many other 
bugs.

Believe it or not, but the X.Org keyboard handling and input system is not 
at all stable, it's in more flux than ever. Eventually it might be very 
nice with MPX and everything, but the fact is that today, there are 
numerous problems both with XKB as well as the classical events.


> Before going further, I need to explain more in depth the major differences between my method and the current one:

Wow, that was a lot of text...


> So, to summarize:
... 
> Even if I'm using XKB as a basis to export new keymaps using my perl script, we really aren't doing anything related
> to XKBlib or using any functions from it. The keycode -> virtual keycode -> scan code mapping is all done using my
> code. We're not doing anything complex here. The only bugs that could affect us related to XKB would be a bug in the
> keycode -> symbolic key code maps. My mapping of symbolic key codes to virtual key codes in my perl script is as
> complete as I could make it. If a bug is found in my perl script, it is trivial to fix and re-export the database.

A quick summarize from my point of view: I'm positive to try to use the 
information in the XKB database. The idea of generating keymaps from it 
using a perl script or similar is nice. This way, however, we should in 
principle be able to keep the current keyboard implementation as-is. We 
could add minor enhancements say trying to detect the keyboard layout 
using XKB if available and things like that, but this would be small, 
independent enhancements that will work with the existing keymap format 
and existing keymaps.

Is there any reason why this approach cannot be used?

Patches must be small and reasonable atomic if I should be able to accept 
them with good confidence. I've downloaded your modified version and 
unpacked it over an existing rdesktop working copy, and the result is a 
"diff" which is 2693 lines long, and I haven't even included the "xkb" 
subdirectory. This is a lot. Small is beautiful.


Regards, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects

_______________________________________________
rdesktop-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rdesktop-devel