Re: [AD] More X Mode Setting

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

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
> 
> ---------------------------------------------------------------------------
> --- Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx