Re: [AD] More X Mode Setting

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On January 14, 2011, Thomas Fjellstrom wrote:
> On January 14, 2011, Peter Wang wrote:
> > On 2011-01-14, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > > > What is the usual behaviour anyway?  If you have a dual monitor
> > > > setup, and you run a game with uses only one screen, should the game
> > > > grab the mouse?  I suppose it depends on the game.
> > > 
> > > I think normally that would be the case. But there should be a way for
> > > the user to ungrab the mouse.
> > > 
> > > > If an API, is this all we need?
> > > > 
> > > >     bool al_grab_mouse(ALLEGRO_DISPLAY *display, bool onoff);
> > > 
> > > That would help.
> > > 
> > > > At any rate, we should leave some control in the hands of the user,
> > > > via the config file and/or a special key which toggles mouse grabbing
> > > > on all Allegro windows (ScrollLock?)
> > > 
> > > I'm not sure we should force the issue, or if we do, make it
> > > disable-able, or make the key configurable.
> > 
> > Ok, should be doable.
> > 
> > > > > Oh, the new xrandr code gets a little "creative" with the
> > > > > _AL_VECTOR type, if you don't mind that, we can leave it, or
> > > > > possibly add a _al_vector_append_array(_AL_VECTOR *vec, int num,
> > > > > TYPE *arr) type function to make the query code a little less
> > > > > creative.
> > > > 
> > > > Yes, please do that.
> > > 
> > > kk. the name ok? or do you have a better suggestion?
> > 
> > It's fine.
> > 
> > > Also, have you had time to look at the lazy init stuff? It doesn't seem
> > > to be necessary on any of my machines to delay the mmon init past
> > > al_create_display. Also I'm not sure we should cater to horrible X bugs
> > > like that too much. Theres already too many X/WM bugs we're hacking
> > > around as it is. That said, I feel a little lame for not being able to
> > > come up with a decent way to keep the full lazy init in tact. Turns out
> > > after making sure windows are placed according to how the api wants
> > > windows placed, respecting the
> > > al_set_new_display_adapter, and al_set_new_window_position etc, we kind
> > > of need to know what monitor we have, and where to place things.
> > 
> > I only looked at it briefly, but it seems we can still do lazy init for
> > the majority of programs, which simply open a window and don't care
> > where it is placed.  I was planning to try it after you commit.
> > 
> > > There is one small possibility, if we check that new display adapter is
> > > -1, we can potentially delay mmon init till the window is moved (so we
> > > can track which monitor its on)
> > 
> > What's the reason for tracking which monitor a window is on?
> > Sorry if it's obvious.
> 
> The main reason is that its used to track which monitors are in use, so we
> can black list multi-displays in x multi-head mode even with true xinerama
> enabled (glx seems to have issues with it, at least it was causing hangs,
> I'll have to test again to make absolute sure it wasn't locking issues,
> but I'm pretty sure it wasn't). I also thought it was being used to make
> it so
> al_get_num_display_modes and al_get_display_mode would actually get the
> modes for the display you're using, but that doesn't make much since, and
> is actually handled by the funky and finicky
> _al_xsys_get_active_window_center function.
> 
> By actively tracking window moves, we don't just limit use to whatever is
> "Screen 0" but just "any one screen at a time". If that can be done in a
> cleaner way, I'm all for it.
> 
> Looking at the window event handling code again reminds me, we still won't
> ever update a display's x and y on moves because of that if() in the event
> handling. So al_get_window_position will always return stale data after the
> window is moved.
> 
> > Peter
> > 

Ok, I think I'm ready to commit what I have. Still need to patch up the grab 
mouse and add _al_vector_append_array. But I thought I'd commit what I have 
now in case you want to release rc5 tonight or tomorrow.

I also need to figure out if its possible to grab the cursor into a "region" or 
multiple windows. That would work the best for multi display uses.

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx