Presently, Xephyr only supports the -size option to specify window dimensions. For multiseat solutions with only one multihead card (or based on eg. Matrox TripleHead2Go) it would be nice to have -geometry to be able to arbitrarily place the Xephyr window. diff will follow shortly.
Created attachment 11331 [details] [review] xephyr-geometry-support.diff Add -geometry support for Xephyr. Patch is based on C3SL's multiterminal patches from http://www.c3sl.ufpr.br/multiterminal/howtos/xephyr-patches.tgz
Trust in your window manager or if you really really need it use something like devils pie.
The Xephyr instances for multiterminal are started by gdm. At this time, no window manager is active. Also, I think that using devilspie may not be easy because all Xephyr instances are named the same.
(In reply to comment #3) > The Xephyr instances for multiterminal are started by gdm. > At this time, no window manager is active. > Using Xephyr for multiseat is a nasty hack at best and I dont want that to polute Xephyr's intended use case and users. I suggest you either write your own sane Multiseat solution and dont abuse Xephyr or just suck it up and live with managing your own patch for your Xephyr modifications. > Also, I think that using devilspie may not be easy because all Xephyr instances > are named the same. > No there not.
(In reply to comment #4) > Using Xephyr for multiseat is a nasty hack at best and I dont want that to > polute Xephyr's intended use case and users. The evdev part of Multiseat has already been committed to git by Tiago Vignatti. These make not much sense except for multiseat: http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=ab3f601149e15789edfb7c9a0c33387070279582 > I suggest you either write your > own sane Multiseat solution and dont abuse Xephyr or just suck it up and live > with managing your own patch for your Xephyr modifications. I still think that this decision is unfortunate, as -geometry support is the only thing missing for excellent multihead support with Xephyr.
(In reply to comment #5) > (In reply to comment #4) > > Using Xephyr for multiseat is a nasty hack at best and I dont want that to > > polute Xephyr's intended use case and users. > > The evdev part of Multiseat has already been committed to git by Tiago > Vignatti. These make not much sense except for multiseat: > http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=ab3f601149e15789edfb7c9a0c33387070279582 > Yes and I've REPEATADLY asked him to revert it. Seems I will have to stop being polite. > > I suggest you either write your > > own sane Multiseat solution and dont abuse Xephyr or just suck it up and live > > with managing your own patch for your Xephyr modifications. > > I still think that this decision is unfortunate, as -geometry support is the > only thing missing for excellent multihead support with Xephyr. > Sorry but mr Xephyr does not want to be part of your nasty lazy multihead hack.
Matthew: For those of us like myself who feel like we have no context... What exactly is being proposed here, and what is your problem with it? I guess I'm not seeing why letting users specify the input and placement of a Xephyr window is such a big deal, or why using Xephyr to do multiseat is evil? I'd love to hear a clear explanation of the issue. Thanks much for any additional comments you might have.
(In reply to comment #7) > Matthew: For those of us like myself who feel like we have no context... > Ok :) > What exactly is being proposed here, and what is your problem with it? I guess > I'm not seeing why letting users specify the input and placement of a Xephyr > window is such a big deal, Its not such a big deal and if normal intended desktop (rather than multiseat) users ask for it then Id apply it (but I do think they would) > or why using Xephyr to do multiseat is evil? I'd > love to hear a clear explanation of the issue. Because to achieve it you have to do nasty things like have Xephyr open evdev directly (as to handle multiple keyboards, mice on a single machine), and other workarounds. I understand the multiseat stuff is very hard todo right and Xephyr presents an 'easy' way to do it but I dont want to end up maintaining the hacks needed to do this nor fix any possible regressions in breaking what Xephyr was originally intended to do (not multiseat..) . What I've suggested to the multiseat guys on numerous occaisions is to just to copy the Xephyr bits of code they need into there own specific kdrive multiseat backend. They are free to do what they want then. I dont see a problem here.
Almost 7 years since this bug has opened, now we have this bug finally solved. Xephyr now supports "-screen WxH+X+Y" option for window placement, as well as a new option "-output NAME". More details in commit messages: http://cgit.freedesktop.org/xorg/xserver/commit/?id=376f4de8ae927748417046390c24afbda24b0583 http://cgit.freedesktop.org/xorg/xserver/commit/?id=84b02469ef97e6f85d074d220a517d752180045f http://cgit.freedesktop.org/xorg/xserver/commit/?id=3a51418b2db353519a1779cf3cebbcc9afba2520
Another ~4 years later, I've only learned of Xephyr because of multiseat. Go figure... (we work on e2k machines, these are powerful but expensive)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.