[blfs-dev] sddm - comments

Ken Moffat zarniwhoop at ntlworld.com
Wed Sep 23 16:57:32 PDT 2015


On Wed, Sep 23, 2015 at 09:56:11AM -0300, Fernando de Oliveira wrote:
> Em 23-09-2015 06:49, Fernando de Oliveira escreveu:
> > Em 23-09-2015 02:19, Bruce Dubbs escreveu:
> 
> 
> >>> There was one other sed, to ensure that those themes which show a
> >>> keyboard flag will get the right flag(s) - I used a variant to force
> >>> a British keyboard only, and it gave me the correct flag
> >>> (previously, I had an American flag in those themes) -
> >>>
> >>> sed -e '/Xsetup/ a setxkbmap "gb"' \
> >>>         -i.orig data/scripts/Xsetup
> 
> I only use -i.orig here, so a can revert without having to untart a new
> source or make a copy of the original source code before starting.
> 

If you keep the built source around, then yes, you can copy the
original script over wherever it gets installed.  I don't.

> 
> >>>
> >>> However, for me, and probably for a _few_ other people, that sed is
> >>> disastrous - it forces the default option for {each,the} selected
> >>> language.  I happen to use two personal variants of the gb keymaps,
> >>> 'deader' (more dead keys - greek, comma, stroke, horn, hook) and
> >>> 'rusphon' (phonetic russian, with some extra cyrillic letters,
> >>> mapped to a GB keyboard).
> >>>
> >>> With that sed, I cannot access any of my additions.  So, I rebuilt
> >>> without that sed.
> 
> First, due to your problem, this will be moved to "Configuration", with
> the sed being applied to
> 
> sed -e '/Xsetup/ a setxkbmap "gb"' \
>        -i.orig
> This will avoid the need to rebuild.

So you are going to do it after the install ?
> 
> Second, I would like to know how you define your keyboards.
> 
> I define mine in
> 
> $ cat /usr/share/X11/xorg.conf.d/00-keyboard.conf
> Section "InputClass"
>         Identifier "evdev keyboard catchall"
>         MatchIsKeyboard "on"
>         MatchDevicePath "/dev/input/event*"
>         Driver "evdev"
>         Option          "XkbModel" "pc105"
>         Option          "XkbLayout" "br"
>         Option          "XkbVariant" "abnt2"
> 

Mine is in 11-keyboard.conf, in the same place :

# Based on a posting on the xorg lists, adapted
#
Section "InputClass"
        Identifier "keyboard-all"
        Driver "evdev"
	# for my own russian variant, specific to a gb keyboard, I put it in gb
        Option "XkbLayout" "gb,gb"
        Option "XkbModel" "evdev"
	# add my own 'deader' gb variant - more dead keys
	Option "XkbVariant" "deader,rusphon"
        Option "XkbOptions" "ctrl_alt_bksp,grp:lctrl_lwin_rctrl_menu,compose:caps"
        MatchIsKeyboard "on"
EndSection

> It is also defined in /usr/share/X11/xorg.conf.d/10-evdev.conf:
> ...
> Section "InputClass"
>         Identifier "evdev keyboard catchall"
>         MatchIsKeyboard "on"
>         MatchDevicePath "/dev/input/event*"
>         Driver "evdev"
> EndSection

Pedantically, the evdev file does not alter the mapping, it only
makes sure it used the evdev driver.

And to add to what I said: I want my keymaps to be available
throughout, without having to use some convoluted invocation.
> 
> I am now with lxqt started from sdddm (runlevel 5). I am using:
> 
> $ cat /usr/share/sddm/scripts/Xsetup
> #!/bin/sh
> # Xsetup - run as root before the login dialog appears
> #setxkbmap "br,us"
> setxkbmap -model pc105 -layout br,us -variant abnt2 -keycodes evdev
> 
> This is the configuration of the keyboard:
> 
> $ setxkbmap -print -verbose 10
> Setting verbose level to 10
> locale is C
> Trying to load rules file ./rules/evdev...
> Trying to load rules file /usr/share/X11/xkb/rules/evdev...
> Success.
> Applied rules from evdev:
> rules:      evdev
> model:      pc105
> layout:     br,us
> variant:    abnt2,
> Trying to build keymap using the following components:
> keycodes:   evdev+aliases(qwerty)
> types:      complete
> compat:     complete
> symbols:    pc+br(abnt2)+us:2+inet(evdev)
> geometry:   pc(pc105)
> xkb_keymap {
>         xkb_keycodes  { include "evdev+aliases(qwerty)" };
>         xkb_types     { include "complete"      };
>         xkb_compat    { include "complete"      };
>         xkb_symbols   { include "pc+br(abnt2)+us:2+inet(evdev)" };
>         xkb_geometry  { include "pc(pc105)"     };
> };
> 
> For facilitating future discussions, these tw other forms also give
> information:
> 
> $ setxkbmap -print
> xkb_keymap {
>         xkb_keycodes  { include "evdev+aliases(qwerty)" };
>         xkb_types     { include "complete"      };
>         xkb_compat    { include "complete"      };
>         xkb_symbols   { include "pc+br(abnt2)+us:2+inet(evdev)" };
>         xkb_geometry  { include "pc(pc105)"     };
> };
> 
> 
> and
> 
> $ setxkbmap -query
> rules:      evdev
> model:      pc105
> layout:     br,us
> variant:    abnt2,
> 
> 
> I can change that during the session (doing now):
> 
> $ setxkbmap -model pc105 -layout br,us -variant abnt2,dvorak -keycodes evdev
> $ setxkbmap -query
> rules:      evdev
> model:      pc105
> layout:     br,us
> variant:    abnt2,dvorak
> 
> 
> I've tried Xsetup with that command with dvorak.
> 
> However, it only modified  sddm-greeter, the session query didn't
> display dvorak:
> 
> variant: abnt2,
> 
> that I understand it is configuring us with default variant.
> 
> >>>
> >>> That will affect anybody who uses a non-default variation in their
> >>> keyboard conf file for X (e.g. Dvorak, perhaps US international [ I'm
> >>> not sure which are the defaults) ].
> 
> Thus, I will include that in the configuration session, with some more
> comments, if we agree, which would include the form of defining the
> keyboard where it wouldn't work and the "flag us" or "??" (double
> question marks" would be preferable, because it will choose the right
> one, when you start typing the password.
> 
> 
> What do you think?
> 

As long as that part is not required, I'm not particularly fussed
about the wording.  Usually, all of us come up with wording which
looks good but later gets misinterpreted.

ĸen
-- 
Il Porcupino Nil Sodomy Est! (if you will excuse my latatian)
  aka "The hedgehog song"


More information about the blfs-dev mailing list