Tomáš Janoušek, blog.

 

Multiseat on demand

We needed to make three computers out of two yesterday, so multiseat was the
keyword I googled for. Having found a bunch of howtos all starting with “make
these changes to xorg.conf and gdm.conf”, I took the best from all of them and
put together a solution requiring no single restart of X server. What I got
was this:

Well, what's the problem? Why didn't I just take the first howto I found? I
wanted to have a sort of “on demand” multiseat, that I can start and stop
whenever I want, without ever touching my main X server and its configuration,
without losing my open windows -- even without having to rearrange them.

What did I need?
* new enough X.org server and Xephyr server with input hotplug support
(I used 1.6.5),
* spare USB keyboard and mouse, spare monitor,
* clever window manager with per-screen workspaces (that's the feature that
lets me switch the external monitor to workspace 12 and still be able to
switch workspaces on my laptop's display) -- I used xmonad, of course.

The theory is that the other seat will run in Xephyr, using the keyboard and
mouse I tell it to use. Xephyr can do that, nowadays, we only need to solve
three little problems:
1. main X server uses that keyboard and mouse as well, and we need to disable
that in runtime,
2. /dev/input/eventN is accessible to root only by default,
3. a lot of keys don't work in Xephyr at all :-).

Feel tree to skip the explanation of these:

1. The xinput command can be used to set device properties, and the “Device
Enabled” property is what we're looking for. Given a device id, this is how we
disable the device in the main X server:

$ xinput list-props id | \
perl -ne 'if (/Device Enabled \((\d+)\):/){ print $1 }' | \
{ read prop; xinput set-int-prop id $prop 8 0; }

2. Being in a hurry, I added Xephyr for my user to sudoers. You may want to
create udev rules to set correct permissions instead.

3. This seems to be caused by Xephyr not using the evdev ruleset for XKB
configuration by default. Running setxkbmap with -rules evdev seems to fix
this problem (see the script for details). Xephyr still seems to have problems
with autorepeat, and I guess that tweaking it for each keycode with “xset r”
might fix it.

Having solved these problems, I wrote a small script that disables the input
devices in your main X server and launches Xephyr that uses them, fixing
keyboard afterwards: http://store.lisk.in/tmp/perm/multiseatxephyr

If called without parameters, it prints a short usage instructions. You'll
have to look into /proc/bus/input/devices to get event devices, and at the
xinput list output to find input device ids. It isn't very robust, but in most
cases you'll be interested in the last two input devices.

Xephyr is running, with access control disabled, all you need to do now is to
su to another user, export DISPLAY=:1 and run startkde (or anything else).

If in trouble, consult the documentation. There are a few links at the X.org
wiki: http://www.x.org/wiki/Development/Documentation/Multiseat

Comments [1]

Going tiled.

I had been using Fluxbox <http://fluxbox.org/> for 7 years when I finally
decided it's time for change last Friday. As my friends expected, I left it
for xmonad <http://xmonad.org/>. Seven years is a long time and for me it
meant that I became a Fluxbox developer. Therefore, I should say some nice
goodbye.

It all started in 2002 when a friend of mine switched me to Linux. I installed
it onto my father's laptop, which only had 32 MB of memory and quickly
realized that GNOME, KDE and Mozilla aren't for me. Someone gave me a tarball
of fluxbox 0.1.12, I installed it, and liked it. Unfortunately, I have no
screen shots or photos from that time.
(just this one: http://foto.nomi.cz/d/22669-2/ja_v_klobouku.jpg :-))

Later that year, I installed fluxbox 0.1.14 (the last in 0.1 series) onto my
“workstation” and it turned out that I would stick with that old version for
another 4 years.

The look of my workspace evolved a little over the years. I chose a few shots
that demonstrate that :-).



In the meantime, Fluxbox team was working hard on the 0.9 series, hoping to
get it stable enough for 1.0. Every time I tried it, it seemed buggy and slow,
bringing nothing new other than transparency and eye candy. The one or two
little features I liked were easy to implement in 0.1.14, anyway. So I stayed
for 4 years.

Then, Mark Tiefenbruck jumped in and made things move faster in 2006. Later
that year, seeing a lot of activity in its svn repo, I decided it was time for
me to jump in as well. Took me only a few patches and it was stable enough for
me to use. I even added some little features I wanted, and managed to get some
of them included in official Fluxbox repo.

At the end of 2007, Fluxbox switched from svn to git and I was given push
(“commit” in svn terminology) access. That year X.org became capable of
switching between single- and dual-head without restarts and I added proper
handling of this stuff to Fluxbox. After that, I had a window manager I was
fully satisfied with. Those few features that never made it into the official
repo were waiting for some polishing on my side that I was supposed to do
after Mark does something I don't really remember what it was. I'm not sure if
he did it, for some time I thought he didn't, and then I focused on other
things and didn't want to hack the window manager that worked perfectly for
me. Well, my fluxbox binary is now more than a year old and will remain that
way. Sorry for that, Fluxbox is a great window manager, I'd like to thank the
people around it, I learned a lot thanks to Fluxbox and the team.

The last day I used Fluxbox, it looked more or less like this:

And one day I switched to xmonad. That day was last Friday. Being a bug-magnet
(as you may have noticed), I've already submitted two patches. But that's
fine, neither was to xmonad core, both were for xmonad-contrib. (I don't want
to blame Fluxbox either. That old 0.1.14 was nearly perfect and latest
versions are probably quite stable as well.)

I really like the configurability of xmonad and the layout modifiers concept.
Also, xmonad-contrib is a huge and very nice collection of useful stuff.
I feel that I'll be submitting more patches (hopefully more than bug fixes) in
the future.

My workspace now looks like this:

So, again, thanks and goodbye to Fluxbox, and I'm looking forward to having
some fun with xmonad :-).

Comments [0]

First post!

Hello,

this is my first post!

My webpage: http://work.lisk.in/

:-)

Comments [4]