regression - display mode detection - more exanples

[hatky]

I don't know why I didn't think of giving you more
examples of what the last change of resolution
changing did but here they are:

gta2 manager now detects these resolutions twice:
640x480
800x600
1024x786
1152x864
1280x960
and the 1400x1050 4 times 
(This manager only displays resolutions without dept)

Gta2 itself now crashes but I am not sure if that is
related or not

p.s. gta2 = grand theft auto 2

as I said Unreal Tournament 2003 no longer finds any
valid display modes (I the traces to some of you and
to wine-devel)

dam, I thought I had more games installed...

and you have the Max Payne problem from Sylvain
Petreolle
(http://www.winehq.org/hypermail/wine-devel/2003/09/0948.html)

I really think this should either be fixed somehow or
reverted (if you want more broken reports you can
release a version :) )

Sorry I didn't find anymore test cases for now,
If you want more traces just ask,
Hatky.

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

[Alex Pasadyn]

hatky wrote:
> gta2 manager now detects these resolutions twice:
> 640x480
> 800x600
> 1024x786
> 1152x864
> 1280x960
> and the 1400x1050 4 times 
> (This manager only displays resolutions without dept)
>
> Gta2 itself now crashes but I am not sure if that is
> related or not

I tried running the demo for GTA2 but it just puts up a window that says 
"Keyboard type not handled".  I've never seen anything like that before 
(plain US keyboard).  I see the resolutions listed twice in the manager, 
though.  I am guessing they are different depths or something.  What 
kind of crash do you get?

As far as the one mode repeated a bunch of times, that's caused by me 
making sure the original desktop size and the real X desktop size are 
both in the list, and I did not check for duplicates.
> as I said Unreal Tournament 2003 no longer finds any
> valid display modes (I the traces to some of you and
> to wine-devel)

I am still confused by this one.  Can you try setting your Wine desktop 
to 512x384 and see if it still complains?  As I told you before, I 
cannot get the demo for that program to run at all, so I am unable to 
investigate it.  It reports (Object Class ObjectInternal created in 
Class instead of Package).
> and you have the Max Payne problem from Sylvain
> Petreolle
> (http://www.winehq.org/hypermail/wine-devel/2003/09/0948.html)

Now this one I totally understand.  The patch I did changed a couple 
things.  There are now three possible modes: Desktop, XVidMode, and 
NoRes.  In desktop mode, you get a preselected list of modes that the 
Wine Desktop can switch between.  In XVidMode mode, the extension 
provides the list of modes.  In NoRes mode, there is no resolution 
changing allowed.

There is a problem that sometimes happens with desktop windows, and it 
seems that changing their sizes makes it happen more often.  Please see

http://www.winehq.com/hypermail/wine-devel/2003/08/0356.html

I worked around this by adding the following hack in 
dlls/x11drv/window.c right before the if (mask) near the end of 
X11DRV_sync_whole_window_position.

     if ((root_window != DefaultRootWindow(gdi_display)) &&
         (mask&&CWSibling)) {
         ERR("desktop mode -- disabling CWSibling\n");
         mask &= ~CWSibling;
     }

I get the BadMatch error just by trying to run two copies of notepad at 
the same time, and this little hack removes that problem and all other 
ones I've seen with desktop windows.  I'm investigating doing that a 
nicer way.  Can you try that out and see if it helps?
> I really think this should either be fixed somehow or
> reverted (if you want more broken reports you can
> release a version :) )

Well, naturally, it needs to be fixed, but the hard part is identifying 
the real problems.  Before this patch, there were three completely 
different sets of hard-coded resolution and depth lists in the wine 
tree.  I changed it so they all funnel through the same code now.  It's 
just a matter now of cleaning up the pieces so they're all happy.  I 
understand that "the games I ran all worked on my two systems" does not 
help you as much as I'd like, but unless I can get some tests I can run 
it's really hard to fix it.

That said, I'm working on an updated patch that will be more "tolerant" 
than the current one.

Specifically, it will:
- include more choices for the desktop size
- always list all modes as including 8, 16, and 32-bit
- silently ignore you when you try to change the depth
- remove duplicated modes (see above)
- include more TRACE lines for better debugging

-ajp

[hatky]

.....
> something.  What 
> kind of crash do you get?
> Seems to not crash with current cvs but blinks all the
> time (not that it dosen't have other errors but the
> blinking is new)...
> both in the list, and I did not check for
> duplicates.
> So I guess this is fixme #1.
> I am still confused by this one.  Can you try
> setting your Wine desktop 
> to 512x384 and see if it still complains? 
> This mode is not in the X config choises (I use the
> mandrake control center, don't now the techi way to
> this), but it's not like windows allows me to set the
> desktop to that, I think only directX is allowed to
> set this mode
> you before, I 
> cannot get the demo for that program to run at all,
> so I am unable to 
> investigate it.  It reports (Object Class
> ObjectInternal created in 
> Class instead of Package).
> :(

...
> ones I've seen with desktop windows.  I'm
> investigating doing that a 
> nicer way.  Can you try that out and see if it
> helps?
> I don't have that game or the specific problem so I
> can't really test that, sorry.
> understand that "the games I ran all worked on my
> two systems" does not 
> help you as much as I'd like, but unless I can get
> some tests I can run 
> it's really hard to fix it.
> I am downloading a few demos now to find some that
> have this problems but seems the my "fast internet"
> isn't fast ength so it take some time, I will mail you
> when I have some demos with this problems I am quite
> sure the diablo2 "video test" will give you some more
> stuff to test but I can't be sure it runs until I
> download it....  (keep you posted on that stuff)
> - always list all modes as including 8, 16, and
> 32-bit
> Do you know sometime a 24 bit mode exists? (some old
> cards did not have 32bit just 24...) (I do not know
> what should be done with it) (in vesa they had the
> same code drived me made writing a vesa game a few
> years back....)
> - silently ignore you when you try to change the
> depth
> Is there a request in the X server project for this
> already? (if not we should at least request as we need
> it)
> - remove duplicated modes (see above)
> ya, fix #1
> - include more TRACE lines for better debugging
> Does that mean I will need to run more traces :( ...
> ;) kidding

p.s. Could you cc me when you send a patch about these
(I fallow only commits)

Hatky.

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

[Lionel Ulmer]

> Specifically, it will:
> - include more choices for the desktop size
> - always list all modes as including 8, 16, and 32-bit
> - silently ignore you when you try to change the depth
> - remove duplicated modes (see above)
> - include more TRACE lines for better debugging

Well, if XVidMode returns only one mode, will your new patch still enumerate
'fake' modes ?

And, yes, somes games will fail if you did strict depth checking (Jedi
Knight being one of them that I am sure of).

So the conclusion : most of the hacks that were here were for a reason :-)

   Lionel (who still have the set of 'offending' patches to review in his
           mailbox but did not yet get around to it :-) )

-- 
		 Lionel Ulmer - http://www.bbrox.org/

display modes

[Alex Pasadyn]

Lionel Ulmer wrote:
> > Specifically, it will:
> > - include more choices for the desktop size
> > - always list all modes as including 8, 16, and 32-bit
> > - silently ignore you when you try to change the depth
> > - remove duplicated modes (see above)
> > - include more TRACE lines for better debugging
>
> Well, if XVidMode returns only one mode, will your new patch still enumerate
> 'fake' modes ?

Here's what I did.  I assume that the users fall into two categories: 
those who want to really change the X server resolutions and those that 
do not.  (I operate in both categories depending on the situation, using 
per-app defaults.)  So, I set it up so that the user will either use 
XVidMode (and set up their X server to include all the modes they want 
to use) or use the Wine desktop (and have access to the hard-coded list 
of modes).

My original patch was not friendly about the depth changing, so I am 
improving that.  Now, it will always enumerate 8, 16, and 32-bit modes 
and silently ignore depth change requests.  This allows the ddraw and 
d3d code to be "clean" so if we ever get depth change support they will 
not have to change.

I wrote a small test program that just lets you test all the modes, and 
I believe that it should now handle all the cases.  I have tested 
starting up a new Wine on a second X server (in Wine desktop mode, with 
no window manager), and that all seems fine, so I think that handles the 
case you talked about a while back.

One thing was that desktop mode had a tendency to crash a lot.  I found 
the error that made that happen (at least on my system) and submitted a 
patch for it yesterday.

I believe that handles all the cases.  Everything I've tested works 
(that worked before anyway).  The only time you don't get any modes 
enumerated is if you are running without the Wine desktop and without 
XVidmode.  Assuming all this new patch works as intended, is there any 
advantage to running that way now?
> And, yes, somes games will fail if you did strict depth checking (Jedi
> Knight being one of them that I am sure of).

That's not one I have but it should be taken care of with this next patch.
> So the conclusion : most of the hacks that were here were for a reason :-)

Yeah I understand that.  My problem is that there are at least half a 
dozen ways to change the resolution that all work on Windows.  I have 
several games installed, and I know that using them I exercised 
ChangeDisplaySettings, D3D8, DDRAW, and they all worked (even with my 
old patch) in both Wine desktop and XVidMode modes.  Hopefully this one 
will be a little friendlier.

-ajp

display modes

[Shachar Shemesh]

Alex Pasadyn wrote:
> My original patch was not friendly about the depth changing, so I am 
> improving that.  Now, it will always enumerate 8, 16, and 32-bit modes 
> and silently ignore depth change requests.

What happens if your real server is at 16bpp, and the app requests 24?

-- 
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/

display modes

[Alex Pasadyn]

Shachar Shemesh wrote:
> Alex Pasadyn wrote:
> > My original patch was not friendly about the depth changing, so I am 
> > improving that.  Now, it will always enumerate 8, 16, and 32-bit modes 
> > and silently ignore depth change requests.
>
> What happens if your real server is at 16bpp, and the app requests 24?

The 24-bit X server depth corresponds to the 32-bit Windows depth.  I 
never fully understood that.  The old hard-coded list of modes only 
lists 8, 16, and 32.  I have my code doing the same, and everything 
seems happy.

My original patch returned a "bad mode" error if you tried to change the 
depth, but it seems some applications just assume they can always change 
the depth to whatever they want.  I saw that there is a "requires 
reboot" code we could try returning instead to see how they like it, but 
for now I will just return "success" as that's what the old code used to 
do.  I was always concerned about faking it like that, but most apps 
seem to be okay.  If they query the settings back they will see the 
"real" depth and that their change to it had no effect.

The good thing is this stuff now only appears one place instead of three 
or four.

-ajp

display modes

[Lionel Ulmer]

On Sun, Sep 28, 2003 at 06:51:24PM -0500, Alex Pasadyn wrote:
> The 24-bit X server depth corresponds to the 32-bit Windows depth.  I 
> never fully understood that.

That's not entirely true... There is not really the notion of 'bits per
pixel' in X. You only have depth (being the number of significant bits per
pixel). So a card with depth 24 can either be in a 24/24 mode (ie one pixel
being 3 bytes - being the 'depth 24' of Windows) or a 24/32 mode (one pixel
== 4 bytes - being the 'depth 32' of Windows).

Note that the 24/24 mode is pretty deprecated now (I think my NVIDIA driver
does not even support it at all) and this is why we mostly only report 8 /
16 / 32.
> My original patch returned a "bad mode" error if you tried to change the 
> depth, but it seems some applications just assume they can always change 
> the depth to whatever they want.

Well, AFAIK, all Windows drivers enable to change the depth on the fly
without reboot.
> I was always concerned about faking it like that, but most apps 
> seem to be okay.  If they query the settings back they will see the 
> "real" depth and that their change to it had no effect.

Anyway, this is OK for DirectX .. as it has its own integrated depth
conversion routines (which I introduced for the aforementionned Jedi Knight
which used 8 bpp for the menu and 16 bpp for the game).

               Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/