Xephyr -geometry patch

davor emard davoremard at gmail.com
Sun Mar 9 17:39:42 PDT 2008

Really a set of small patches would be no problem, we can
package them up nice in deb, rpm, ebuild etc. so they will
practically be invisible for ordinary users.

in xephyr, there's non-working -origin x,y
(claimed to work for xinerama but I guess it's just a NOP)
A -geometry and -display are just sign of good intention to
clean implement xepyhr's commandline options like other X
applications all have.

I've seen certain amount of "dirtiness" in the xephyr code so a
bit of development traffic should help clean the dirt and make it
better and more useful for everyone

After all isn't unix meant to be universal os and shouldn't
pepole every day discover new field of application for old
tools that initial author didn't even think they could be used for?
so I think xehpyr and xorg as well would benefit from some extra

Best regards, Davor

On 3/9/08, Alan Cox <alan at lxorguk.ukuu.org.uk> wrote:
> > Fork the project tends to also fork developers. This is what motivated
> > me to not build another separated DDX for multiseat.
> >
> > (and I think no one judges sane to fork Xephyr just because Matthew
> > Allum doesn't want a simple -geometry there. So sad)
> When you've got a developer who simply refuses to make their project work
> with other peoples either by offering no solution or refusing to take
> small patches for features on fairly narrow grounds the question in my
> experience is not if but when there will be a fork. That may well be an
> amicable forking or something that is a set of patches pretending not be
> a fork for a while but in the end pragmatism usually wins.
> Alan
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg

More information about the xorg mailing list