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:
> > re-factor working now, at least on my laptop, attached the new patch.
> > 
> > I'll remove the old xrandr code in a second commit, just to make sure the
> > code is around some place. right now its just #if 0'ed out.
> > 
> > All of the new xrandr code lives in src/x/xrandr.c now, split out from
> > src/x/xfullscreen.c, its considerably cleaner, makes it a lot easier to
> > work with and improve. And it works at least as well as the old code
> > did, if not better (it will for sure once I add the logic to detect
> > monitor relationships and change monitor origins, to fix mouse behavior
> > with multiple monitors).
> > 
> > We also need to figure out a way to fix the mouse grabbing. The way it
> > was, totally broke multi monitor. The way it is now, breaks single
> > monitor full screen (it just doesn't grab the mouse at all right now).
> 
> FWIW: randr/single monitor - cursor confined as expected.

Oh, dur. I meant single display, dual monitor. If you have two monitors, but 
only have one allegro display, the mouse isn't contained, you can mouse over 
into your other monitor.

> 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.
 
> > 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?

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.

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) or the user uses a mmon function. Otherwise we kind of 
need to query for the mmon data in al_create_display. Potentially if the user 
never uses any mmon functions, and new_display_adapter is always -1, and so is 
d->adapter, we could then skip mmon init too. It would work for many simple 
examples and such. But I'm sure I'm forgetting some details as to why I didn't 
do that to begin with.

> 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