Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Some multi-seat issues

  1. #1
    Join Date
    Jun 2009
    Posts
    2,929

    Default Some multi-seat issues

    Hi all,

    Yesterday, I set up a dual-seat configuration, by pretty much following the tutorial here, but on Gentoo, and with a pretty recent r600c/Mesa/kernel stack. It works great, for the most part, which is quite amazing.

    However, I'm having serious trouble with VT switching. Here's roughly what I'm seeing:

    - When booting, kernel uses the HD 4550 for output. As soon as radeon driver loads and resets the resolution, it switches over to the HD 4350.
    - The two KDMs show up on respective monitors and I can log in on both, everything works pretty much as expected.

    But:

    - When the HD 4350 (the active one) goes to sleep (DPMS), X doesn't come up again on wake-up, but an empty screen with a prompt (like an empty screen on an unused VT). I haven't managed to get KDM back on that screen short of /etc/init.d/xdm restart
    - VT switching is still active. When I press Alt+F2 in KDE (for the "run command" interface") on the first X server running on the 4550, the VT on the other display switches over to the VT, and the VT gets all of my keyboard input. The first X session still works, but everything is echoed on the second display showing the VT.

    The latter is extremely annoying, not only because it keeps trying to log on, but because I've actually managed to (accidentally) log in as root on the VT and edit xorg.conf by accident, and totally botch it. This is the weirdest thing that's ever happened to me

    The tutorials say that you should disable fbcon, but surely without fbcon, you just don't get to see the VT text, but it's still there, so the security and usability problems are still there. It seems like the console is still listening to both keyboards although X is active, and this is not the way it should be. Should I disable the VTs somewhere in the kernel?

    "DontVTSwitch" in xorg.conf doesn't do anything.

    Have any phoronix users done something similar, or have any ideas?

  2. #2
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    Actually, it's quite odd.

    I can switch to the "disappeared" X session, but only the mouse pointer is drawn, the rest of the screen shows the "empty" tty. All the apps are still there, and the mouse pointer changes, so I can log in using kdm, kde starts, I can move the mouse, etc, but nothing else is drawn.

    The screen on my HD 4550 (the secondary adapter, I'm guessing) is not affected at all, since it doesn't show console output anyway.

  3. #3
    Join Date
    Nov 2008
    Posts
    770

    Default

    I've read about the DPMS problems before. It's what you get for using the -sharevts -novtswitch hacks.

    Try
    > xset -dpms
    or
    > xset s off
    in your X init scripts.

  4. #4
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    Thanks, that might do the trick with DPMS.

    It would be great if someone knew how to deal with the console switching, I'm so used to pressing Alt+F2 that I can't stop myself from doing it

  5. #5
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    Nope, didn't help It still went to sleep and woke up broken.

  6. #6
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    OK, I seem to have fixed the tty problem, based on this howto here.

    The trick is to only used -sharevts on the first seat, and use -keeptty for both.

    It only seems to affect some configurations, but it fixed it for me.

    Sorry for the multiple posts, but the editing is disabled, and I thought it might help somebody with the same problem.

  7. #7
    Join Date
    Nov 2010
    Posts
    21

    Question

    I have quite similar 2-seat setup with a HD4290 (RS880, really ~RV620) and a Juniper HD5750.

    The DPMS-problem is evident here. My solution is to ssh in as the problematic seat/user and run:
    Code:
    'xset -display :[seat number].0 force dpms on'
    Sometimes this is required every time, but usually only after the first DPMS off event after logging in. This is only problem with the other seat. DPMS does not always activate if the other seat is in use.

    Do you have a problem with hot-plugging input devices? My other seat always steals (grabs) the input device and while I can use 'xinput' -program to float it, the other seat fails to see the device.
    During bootup, unless I put:
    Code:
    Option  "GrabDevice"    "true"
    to xorg.conf, input devices are usable from both seats and have to be disable with xinput -float selectively.

  8. #8
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    I haven't tried hot-plugging input devices, but I assume that it should be OK if you attach the device id (not path) to a screen in xorg.conf, like you have to do for regular keyboard and mouse. If they are not mapped to a particular seat, then all of them will get it.

    The dpms thing went away after I fixed the tty issue. I think it's the -keeptty option which fixed it.

  9. #9
    Join Date
    Nov 2010
    Posts
    21

    Default

    Great. I'll test the keeptty-switch after rebooting (which might take a while).

    My problem with hotplugging input devices is that you can't always define those in xorg.conf in advance. One does not know beforehand what devices will be connected and for who. Also occasionally I would like to move a certain device to another seat.

    When I hotplug a device defined for the seat A for some reason the seat B always grabs it faster and blocks the seat A. And when launching X and a device is defined in xorg.conf without GrabDevice it shows up in both/all the seats and with xinput can be disabled disabled from wrong seats.

  10. #10
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    You don't need to reboot, just restart xdm.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •