4 thoughts on “Xinerama”

  1. I think you’ll need to leave xinerama support for a few more years. It’s not like it’s a lot of code or anything, and should be trivial to abstract xinerama vs. whatever the new thing is and support both. Or just keep using xinerama until the X guys actually delete it.

    The sf.net project was to document/standardize xinerama I think, it had never been formally standardized iirc.

  2. Unfortunately some of us are stuck on binary drivers without xrandr 1.2 support, so no, Xinerama support shouldn’t be dropped.

  3. Havoc is right – the sf.net project was the old X.Org Xinerama Standards Committee, not the Xinerama extension or API, which remain fully supported by X.Org. Development of those happens on freedesktop.org now, not sourceforge.net.

  4. Even with xrandr 1.2 using libxinerama makes sense imho. libxinerama provides an API for programs to know about the screen geometry, while xinerama itself is one out of many ways to implement dual-head, the popular one being RandR-1.2 these days, but libxinerama has always exposed the basic multi-head geometry on MergedFB and RandR-1.2 system as well as far as I recall (definitely with MergedFB, not 100% sure with RandR-1.2 as I don’t have dual-head since radeon driver got it)

Leave a Reply

Your email address will not be published. Required fields are marked *

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.