Re: [AD] More X Mode Setting

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On January 4, 2011, Thomas Fjellstrom wrote:
> On January 4, 2011, Thomas Fjellstrom wrote:
> > On January 4, 2011, Peter Wang wrote:
> > > On 2011-01-04, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > > > On January 4, 2011, Peter Wang wrote:
> > > > > On 2011-01-04, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> 
wrote:
> > > > > > What do people think should happen? Do we even support xf86vm? It
> > > > > > seems to have too many problems. the scrolling would make most
> > > > > > apps using two monitors virtually useless. Dropping xf86vm would
> > > > > > mean no modes or mode setting available in places where xrandr
> > > > > > isn't available (real xinerama for example, the nvidia driver
> > > > > > seems to disable xrandr when
> > > > > > multi-head+xinerama is enabled).
> > > > > 
> > > > > AFAIK there is no solution.  If you want, feel free to restrict
> > > > > XF86VidMode to single monitor use.
> > > > > 
> > > > > X really, really doesn't want you to change the resolution.  Even
> > > > > with randr, it is going against the grain, otherwise the API would
> > > > > have some provision to automatically restore the display mode on
> > > > > exit. So, I wouldn't worry to much about it.
> > > > 
> > > > XRandR actually works rather well for Allegro's use. Should I add
> > > > another hard coded check for "more than one monitor" for this case,
> > > > or just keep the XGrabPointer, so it will just lock the mouse to one
> > > > of the displays? That would effectively make it near impossible to
> > > > actually use additional displays for anything.
> > > 
> > > I don't have dual monitors set up right now, so I don't know what the
> > > current behaviour is.  If it works without XGrabPointer, that would be
> > > best.
> > 
> > XRandR probably does. XF86VM does not, currently.
> > 
> > Thats another question I meant to ask though. In many single screen games
> > you definitely want to lock the mouse to the window, but at some points
> > you're going to want to break out, so you can mouse over to another
> > monitor. Should we add a way to grab and ungrab the mouse? I can see this
> > being used on all the main PC platforms to some degree.
> > 
> > > > > See also my and Matthew's independently arrived-at ideas for
> > > > > "emulating" fullscreen modes.  We did it for non-matching colour
> > > > > depths in A4, we can do it for non-matching resolutions modes in
> > > > > A5.
> > > > 
> > > > Then at some point we'd provide some "virtual" modes? Or just allow
> > > > setting of modes that don't appear in the mode lists? Right now, at
> > > > least with the X implementation, if the mode isn't in the mode list,
> > > > it can't/won't set it. (xrandr and xf86vm both theoretically support
> > > > adding modes on the fly... but I haven't really bothered to look
> > > > into supporting that)
> > > 
> > > It would be a good place to start, but I see no technical reason to
> > > restrict ourselves to the modes set up in the X server.  Although the
> > > mode lists are usually detected nowadays, so likely to be comprehensive
> > > anyway.
> > 
> > The only time I'm stuck without modes is when I've setup TwinView on
> > nvidia, and haven't setup any TwinView modes. Though those are somewhat
> > special, and you probably can't set those up through XRandR or XF86VM.
> 
> Yeah, looks like more than one monitor in use at any one time is completely
> broken outside of native XRandR modes. So no using multiple adapters on
> multi- head+xrandr, or xf86vm+xinerama.
> 
> The former gives an X error, and then locks up in a pthread mutex, and the
> latter has mouse issues that make is less than useable.
> 
> > > Peter

Another issue. Window movement. Seems with compiz, and a window with a 
border/titlebar, we get sane amounts of window movement events, but in 
ex_noframe, we get a ton. (I'm assuming the wm is compressing all the events 
into just a few per window move)

At least thats what happens if I comment out that if at the bottom of the 
configure event handler. Otherwise we never update the window's position at 
all. It seems I don't even get that bogus configure event the comment above 
mentions.

I'd like to also flag the code to update the display's new adapter property 
there, but if that if is really needed, we never get a chance. Can I just 
remove that check?

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx