Menu
▾
▴
vectorlinux-devel
|
From: hanumizzle <han...@gm...> - 2006-06-29 16:02:20
|
These questions (pretty important) didn't get answered on the board, so I am asking it here: I have **more or less** squared away the first four basic VASM apps I decided to write (we still have weird segfault problems with the menu translators, but I'm working on that, too). Most of it is gravy from here on in, but, being a hacker, I wanted to take on the tricky parts first. To that end, I will be moving to the X configuration program next. I gave up on the idea of writing an actual grammar for the file, and instead will use the Perl Way(tm): lots of regexes. It seems the most pragmatic thing to do. However, I have run into a couple questions, mostly involving keyboards: * I know jack about X keyboard configuration. Every time I needed to input i18n text (German and Devanagari scripts, basically), I did it in Emacs or Yudit. Arey! Any help on the architecture of X keyboard support? * How should I integrate console keyboard support with X keyboard support? Or should I let them be separate? * I've heard complaints about getting foreign keyboard layouts to work. I believe they should Just Work(tm). How did you solve your problems? * Any unusual hardware quirks I should take into account? I know (as of Xorg 6.8.2) that Via Unichrome cards are not supported by the 'via' driver, and that they need the 'vesa' driver to work properly. More recent versions of Xorg have built-in Unichrome support * cdialog configuration of X is sufficient, yes? I don't think having a GUI version is really necessary. Any other special requests...? |
|
From: Oleg <ya...@gm...> - 2006-06-29 23:03:09
|
> * I know jack about X keyboard configuration. Every time I needed to
> input i18n text (German and Devanagari scripts, basically), I did it
> in Emacs or Yudit. Arey! Any help on the architecture of X keyboard
> support?
Do you need help on xorg.conf keyboard configuration format or on keyboard
switching tool?
Anyway, below is my configuration, and I use "kkbswitch" package for switching
keyboard layout.
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "CoreKeyboard"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us,ru(winkeys),ua(winkeys)"
Option "XkbOptions" "grp:caps_toggle,grp_led:scroll"
EndSection
Option "XkbLayout" is a list of languages to switch between, in my case
English, Russian and Ukrainian. In your case there would be
Option "XkbLayout" "us,de"
I don't know about Devanagari support.
Now "winkeys" in my configuration is a variant of keyboard layout, for
different languages there are different sets of layouts, I think you can get
the full list via
grep -o "pc/.*(.*)" /etc/X11/xkb/symbols.dir
Next line:
Option "XkbOptions" "grp:caps_toggle,grp_led:scroll"
grp:caps_toggle sets the way of persistent toggle of keyboard layout.
Full list of toggle options:
grep -o "group(.*_toggle)" /etc/X11/xkb/symbols.dir
There are also "switch" options, see
grep -o "group(.*_switch)" /etc/X11/xkb/symbols.dir
They allows to toggle layout temporarily, when the switch key is pressed.
Next option, grp_led:scroll set the indicator of layout change.
The full list of variants is here:
grep -o "leds(.*)" /etc/X11/xkb/compat.dir
> * How should I integrate console keyboard support with X keyboard
> support? Or should I let them be separate?
Console keyboard is another story. It has another set of layouts, switches,
toggles, etc. Generally it's more restricted than X. E.g., it's quite hard to
configure switching between 3 layouts (I did this in console-cyrillic package
for en-ru-uk, but AFAIK there is no general solution).
So if you don't want to restrict X keyboard setup, don't integrate it with
console keyboard setup too tightly.
If someone need only 2 languages, such integration may make sence, though.
> * I've heard complaints about getting foreign keyboard layouts to
> work. I believe they should Just Work(tm). How did you solve your
> problems?
Include "kkbswitch" package into default VL installation. I haven't heard
about any other keyboard switching tool which Just Work(tm).
> * cdialog configuration of X is sufficient, yes? I don't think having
> a GUI version is really necessary.
I don't agree. One may want to setup X keyboard via GUI.
KDE Control Center allows some X settings via GUI.
|
|
From: Vanger <fa...@gm...> - 2006-06-30 09:59:56
|
> Option "XkbRules" "xorg" > Option "XkbModel" "pc105" > Option "XkbLayout" "us,ru(winkeys),ua(winkeys)" > Option "XkbOptions" "grp:caps_toggle,grp_led:scroll" I want to add, that xorgconfig's approach, setting > > * How should I integrate console keyboard support with X keyboard > > support? Or should I let them be separate? > Console keyboard is another story. It has another set of layouts, switches, > toggles, etc. Generally it's more restricted than X. E.g., it's quite hard to > configure switching between 3 layouts (I did this in console-cyrillic package > for en-ru-uk, but AFAIK there is no general solution). > So if you don't want to restrict X keyboard setup, don't integrate it with > console keyboard setup too tightly. > If someone need only 2 languages, such integration may make sence, though. > > > * I've heard complaints about getting foreign keyboard layouts to > > work. I believe they should Just Work(tm). How did you solve your > > problems? > Include "kkbswitch" package into default VL installation. I haven't heard > about any other keyboard switching tool which Just Work(tm). > > > * cdialog configuration of X is sufficient, yes? I don't think having > > a GUI version is really necessary. > I don't agree. One may want to setup X keyboard via GUI. > KDE Control Center allows some X settings via GUI. > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Vectorlinux-devel mailing list > Vec...@li... > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel > |
|
From: Vanger <fa...@gm...> - 2006-06-30 10:22:11
|
In any configuration, there should be "us" layout by default. Doesn't matter, how much you love our native non-latin language, but you can't configure system by it. > Option "XkbRules" "xorg" > Option "XkbModel" "pc104" > Option "XkbLayout" "us,ru(winkeys)" > Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll" This is the perfectly working configuration. But I always have to set it manually. xorgconfig is dumb, when you try to set up your language in it, it makes a non-working configuration: Option "XkbLayout" "ru" Option "XkbVariant" "ru(winkeys) And if you change the default - "XkbLayout" - on "us", you can't switch on Russian or back. I even have seen such variant: Option "XkbLayout" ""us","ru"" in a Deepstyle Linux (Russified and Ukrainized Slackware). That doesn't work either. So, the final variant shold be: Option "XkbLayout" "us,<other languages>" Option "XkbOptions" "grp:<toggle>,grp_led:<if someone wish>" > * How should I integrate console keyboard support with X keyboard > support? Or should I let them be separate? It's quite easy - you have to load the needed font, load the needed keyboard layout and enable mapping on ttys. For Russian it looks like this: setfont koi8r_8x16 loadkeys ru-ms for n in 1 2 3 4 5 6; // similar for all languages do echo -ne "\033(K" > /dev/tty$n done I think, it can be automated, but I don't like the idea of integrating with X. > * cdialog configuration of X is sufficient, yes? I don't think having > a GUI version is really necessary. It is not critical, but it would be good to see it. > I don't agree. One may want to setup X keyboard via GUI. > KDE Control Center allows some X settings via GUI. But they don't work, because they rely on KDE's switcher ;) . |
|
From: Oleg <ya...@gm...> - 2006-06-30 14:36:48
|
2006/6/30, Vanger <fa...@gm...>: > I think, it can be automated, Yes, just install "console-cyrillic" package from VL repository and look at the "cyr" script contained in it. |
|
From: Vanger <fa...@gm...> - 2006-06-30 16:35:19
|
> Yes, just install "console-cyrillic" package from VL repository and > look at the "cyr" script contained in it. I mean, not only for Russian/Ukrainian, but for other non-latin languages. |
|
From: hanumizzle <han...@gm...> - 2006-07-01 06:30:51
|
On 6/30/06, Vanger <fa...@gm...> wrote: > In any configuration, there should be "us" layout by default. Doesn't > matter, how much you love our native non-latin language, but you can't > configure system by it. OK. > > > Option "XkbRules" "xorg" > > Option "XkbModel" "pc104" > > Option "XkbLayout" "us,ru(winkeys)" > > Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll" > This is the perfectly working configuration. But I always have to set > it manually. This is what I meant by the phrase 'just works'. c.f. http://c2.com/cgi/wiki?ItJustWorks > xorgconfig is dumb, when you try to set up your language in it, it > makes a non-working configuration: > Option "XkbLayout" "ru" > Option "XkbVariant" "ru(winkeys) > And if you change the default - "XkbLayout" - on "us", you can't > switch on Russian or back. > > I even have seen such variant: > Option "XkbLayout" ""us","ru"" > in a Deepstyle Linux (Russified and Ukrainized Slackware). That > doesn't work either. sux0rz... > > So, the final variant shold be: > Option "XkbLayout" "us,<other languages>" > Option "XkbOptions" "grp:<toggle>,grp_led:<if someone wish>" > > > > * How should I integrate console keyboard support with X keyboard > > support? Or should I let them be separate? > It's quite easy - you have to load the needed font, load the needed > keyboard layout and enable mapping on ttys. For Russian it looks like > this: > > setfont koi8r_8x16 > loadkeys ru-ms I'm good up to here: set the console font and load a certain keymapping for raw keycodes. > for n in 1 2 3 4 5 6; // similar for all languages > do > echo -ne "\033(K" > /dev/tty$n > done WTF? (BTW, the `seq' program can generate number sequences; it has all kinds of features for padding and the like.) for n in $(seq 1 6); do echo -ne "\033(K" > /dev/tty$n done Doesn't setterm -reset do something like that? > I think, it can be automated, but I don't like the idea of integrating with X. Here's the plan. I'll write a class for XOrgConfig that chops up an xorg.conf. Methods for such an instance will do distinct things like: $xorgConfig->SetDefaultDepth(16); or $xorgConfig->SetKbds(qw/en ru/); that way individual applets can be written for each part of the configuration...there is a lot of flexibility here. Say vkeyset does one routine for console keyboards and another for X keyboard setup. The other X tools will act independently of this feature. Complete orthogonality. And the 'main' X config program will simply run vxresset, vxmouse, vkeyset (passed -noconsole option to skip console part). If it doesn't make sense, I was really tired when I wrote this. > > * cdialog configuration of X is sufficient, yes? I don't think having > > a GUI version is really necessary. > It is not critical, but it would be good to see it. If I have time. I'm not sure where the practical benefit would be. > > I don't agree. One may want to setup X keyboard via GUI. > > KDE Control Center allows some X settings via GUI. > But they don't work, because they rely on KDE's switcher ;) . Does it sux0rz? P.S. - It's good to have Russian folks working on your computer project; their skills are undervalued IMO -- Remember that time Thotsakan punched Neil Bush in the dick? |
|
From: Oleg <ya...@gm...> - 2006-07-01 10:04:52
|
hanumizzle wrote: > Here's the plan. I'll write a class for XOrgConfig that chops up an > xorg.conf. Methods for such an instance will do distinct things like: > $xorgConfig->SetDefaultDepth(16); or $xorgConfig->SetKbds(qw/en ru/); > that way individual applets can be written for each part of the > configuration...there is a lot of flexibility here. Say vkeyset does > one routine for console keyboards and another for X keyboard setup. Sounds good! > > But they don't work, because they rely on KDE's switcher ;) . > > Does it sux0rz? KDE keyboard switcher doesn't work for years, that is why kkbswitch was created. |
|
From: hanumizzle <han...@gm...> - 2006-07-02 03:48:11
|
On 6/29/06, hanumizzle <han...@gm...> wrote: > These questions (pretty important) didn't get answered on the board, > so I am asking it here: > ... > However, I have run into a couple questions, mostly involving keyboards: A few more came up: - What if someone has multiple heads / mice / keyboards? - To what degree should the config tolerate user editing? This raises several issues: * Should the config program support the user's style of indentation dynamically? * What if a user deletes SubSections for certain depths? How should depth setting method handle this? Search for the ones that do exist? -- Remember that time Thotsakan punched Neil Bush in the dick? |
|
From: Oleg <ya...@gm...> - 2006-07-02 08:10:36
|
h> On 6/29/06, hanumizzle <han...@gm...> wrote: h> - To what degree should the config tolerate user editing? This raises h> several issues: h> * Should the config program support the user's style of indentation h> dynamically? No, just use some default style, e.g. the style which X.Org developers use in default xorg.conf, or something like that. h> * What if a user deletes SubSections for certain depths? How should h> depth setting method handle this? Search for the ones that do exist? IMHO this situation is more like user's mistake. Can you generate missing sections automatically? |
|
From: hanumizzle <han...@gm...> - 2006-07-02 08:23:25
|
On 7/2/06, Oleg <ya...@gm...> wrote: > h> On 6/29/06, hanumizzle <han...@gm...> wrote: > h> - To what degree should the config tolerate user editing? This raises > h> several issues: > > h> * Should the config program support the user's style of indentation > h> dynamically? > No, just use some default style, e.g. the style which X.Org developers > use in default xorg.conf, or something like that. > > h> * What if a user deletes SubSections for certain depths? How should > h> depth setting method handle this? Search for the ones that do exist? > IMHO this situation is more like user's mistake. > Can you generate missing sections automatically? Yes, but working with xorg.conf files gets very nasty, very fast. I *could* add the subsections if missing. I could also write a web server in COBOL if I really tried. :( To date, there is no Xorg module on CPAN. And they have nigh everything: CSV, fstab, XML, YAML (which I would have used if I knew about it earlier), MIME, etc., etc., etc. No Xorg config. But why? Because the format sucks, and I hate it. -- Remember that time Thotsakan punched Neil Bush in the dick? |
|
From: Kocil <k0...@ya...> - 2006-07-15 12:18:52
|
I gave some answer in the board. If you want to see a little trick on reading/modifying xorg.conf, please read the vxconf script. I wrote an interesting (or should I say an introductury) state machine parser there. --- hanumizzle <han...@gm...> wrote: > These questions (pretty important) didn't get > answered on the board, __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: hanumizzle <han...@gm...> - 2006-07-16 02:15:37
|
On 7/15/06, Kocil <k0...@ya...> wrote: > I gave some answer in the board. > If you want to see a little trick on reading/modifying > xorg.conf, > please read the vxconf script. > I wrote an interesting (or should I say an > introductury) state machine parser there. No need to worry, I think I have an answer. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X