Yuri Bushmelev wrote: > Thank you for your work! > Can you please measure memory load? Just to compare kdrive vs xorg.
Yes, I can. > > Todo: > What are that operations? > > - Implement chvt to the keymap. Several lines in the keymap. > > - Migrate touchscreen to evdev or fix tslib driver crash on chvt. Find what is broken on touchscreen support (I seen a patch somewhere). It may require upgrade to the latest kernel (click seems to not being generated by old kernels). > > - XRandR is not yet supported. Rotation is supported only when server starts using ShadowFB. But X thinks that hardware supports rotation, fbdev driver on Zaurus can't. The code to support software based rotation on fly is missing. > > - Some operations are much slower than they were on kdrive. It seems that some operations are performed on unrotated buffer, which introduces inefficient random access to SDRAM. It seems to be filling screen and block move. Maybe comparing with kdrive code could help. > > - Adapt daemons to new key codes. Use keycodes that should be used. Don't force its own hardwired xmodmap commands (gpe-dm does). > > - Think again about keymaps that need AltGr+Numbers (cz). What should > > take precedence? Move Brightness or AltGr+Number to Fn+Shift? Or move > > it elsewhere? > > May be map them just to Alt+Number? It may conflict with Alt+Number hotkeys. (Well Alt+Fn+Number may cause problems as well, but they are a bit more rare.) > Or you can use Calendar or Menu key e.g. > as modificator. It might be possible. Now I use always Fn+3/4 for brightness and Fn +Shift+3/4 for #/$ in cz and Shift+3/4 for #/$ in us. > Or just remove brightness bindings for keymaps with > AltGr+Number. Brightness binding should be somewhere. I would prefer following printed symbols as far as possible. It's easier to type then. I would hardly imagine having different brightness-up in "us" and "cz" keymaps. I was using LAlt+3/4 for brightness in cz map in past, but then I returned to Fn+3/4. I am not sure what is better. In both cases I made mistakes - once typing "$", second type while raising brightness. > > - Think about use of unused keys. > > - Implement Compose. > > Same thing here. I'll prefer using Calendar - Menu keys for this. Well, I would think about keeping PIM symbols there (for people who like PIM) or map there important window manager actions for people that don't like PIM (as an alternate map). I was mapping WM actions there in past: Rotate windows, Close window, Show Desktop/Menu. It was very comfortable - I didn't have to pick my stylus often. > > - How to discriminate OK, OK, Enter and Esc, Cancel. > > - Maybe set slower repeat rates for some special keys instead of turning > > it off. > > - XKB geometry > > How are (should be?) mapped wheel, Not yet, thinking about Fn+RAlt+arrows. RAlt+Arrows to map mouse movement, RAlt+OK/Esc/something - mouse click. But I have to learn XKB a lot to be able to do it. It would mean more work than it sounds. After using of these keys, cursor must become visible. Fn+Tab->Caps_Lock is a XKB black magic. Implementing that took many hours of docs reading and experimenting. > screen keys No idea. Well, I had an idea about application-specific GUI mapping to selected actions (and pop-up with description). > and functional keys > (Calendar/Address/Mail/Home/Menu)? XF86Calendar, XF86Book, XF86Mail, XF86HomePage, XF86MenuKB. And F-keys are mapped to RAlt+numbers, but it seems to be half working - xev reports them, but mc gets only Esc sequences. > Seems I should prepare russian phonetic keymap too :) Note that my map is still a subject of changes. -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus _______________________________________________ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel