Difference between revisions of "Talk:Display manager"

From ArchWiki
Jump to: navigation, search
(close topic.)
(xinitrc: rm old discussion)
Line 1: Line 1:
== <s> xinitrc </s> ==
 
Hi Archies :)
 
 
Using this wiki gave us some little trouble since both methods (1st & Alternate method) do say nothing about necessary ~/.xinitrc configuration.
 
 
Yes this is "not to mention" to lot of people.
 
 
But some may be in the same situation than me, who did not use .xinitrc before, since I always start from command line : startxfce4 / kde / whatever WM
 
Thereafter I didn't check the ~/.xinitrc file since we installed Arch Linux.
 
And it showed the wrong configuration like "exec fluxbox" --but we do not have that WM installed...
 
 
''So to say we spent a bunch of time googling before I thought about the .xinitrc :(''
 
 
'''I suggest to add a line about one needs to check his ~/.xinitrc after point 5.''' (Alternate Method)
 
: This is not needed after all of the changes about systemd. Close. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 12:59, 25 November 2012 (UTC)
 
 
 
== <s> non-us keyboard mapping </s> ==
 
== <s> non-us keyboard mapping </s> ==
  

Revision as of 11:37, 30 May 2013

non-us keyboard mapping

hi there :)

as non-us keyboard user, I notice that gdm only uses the default us keyboard map. With the new version of xorg, which uses hal to auto-configure the hardware, it's not possible to force different layout anymore.

The only thing I found working is to create the file /etc/hal/fdi/policy/10-keymap.fdi and put this content on it:

/etc/hal/fdi/policy/10-keymap.fdi
<?xml version="1.0" encoding="ISO-8859-1"?> 
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.keymap">
<append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
</match>

<match key="info.capabilities" contains="input.keys">
<merge key="input.xkb.rules" type="string">base</merge>

<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
string="Linux">
<merge key="input.xkb.model" type="string">evdev</merge>
</match>
<merge key="input.xkb.layout" type="string">YOUR KEYBOARD LAYOUT</merge>
<merge key="input.xkb.variant" type="string">YOUR KEYBOARD LAYOUT VARIANT</merge>
</match>
</device>
</deviceinfo>

The two strings for the respective keys input.xkb.layout and ~variant, should be the same of those that xorg used to load via xorg.conf, under Device section: "XkbLayout" and "XkbVariant".

I use a Swiss keyboard, French variant, so for the xorg.conf standard method it was:

/etc/X11/xorg.conf (just keyboard section)
Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option "XkbModel" "pc105"
	Option "XkbLayout" "ch"
	Option "XkbVariant" "fr"
EndSection

and with the new hotplug method it will be:

/etc/hal/fdi/policy/10-keymap.fdi (just the keymap key entries)
<merge key="input.xkb.layout" type="string">ch</merge>
<merge key="input.xkb.variant" type="string">fr</merge>

This way it works, and now I can log in using my keyboard layout, so I won't type the wrong password anymore. Hope this help :)

PS: disable the hotplug feature by putting

/etc/X11/xorg.conf (hotplug disable)
Section "ServerFlags"
	Option "AutoAddDevices" "False"
EndSection

did not solve the problem: gdm still use the default us layout.

and PS2: sorry for the english :) grammar correction will be appreciated :)

This topic is too old. HAL is long gone. Close. -- Fengchao (talk) 12:44, 25 November 2012 (UTC)

Manager Choices

Where is the listing of login managers? - KitchM 01:18, 10 November 2009 (EST)

There is a list now. Close. -- Fengchao (talk) 12:59, 25 November 2012 (UTC)

Incorrect Explanation?

IMHO, a display manager is not a login manager. The login manager handles just the part of the process that gives the user a place to login and interfaces with the OS authorization process to recognize the user. The display manager can provide a login manager, but primarily handles the starting of the rest of the graphical interface by starting a new session on a local or remote system.

In the first place a user is given the green light to use the system, but nothing further occurs. In the second, the user is given the interface with which to work.

I think we need to be a little more precise and clear, and there should be more details. - KitchM