screeninfo now also prints the color space and whether overlay is supported

[hypgci]

Modified screeninfo so that it also prints the color space and whether overlay is supported.

[pulkomandy]

I think this is not exactly what was requested.

First a little background on Overlays: this is a feature of some video cards, that allows putting a separate image (usually a video) above the normal display. The overlay and main buffer are entirely separate, and can have different color spaces. The main use for this is playing a video file (usually in some YUV colorspace) over an RGB desktop, and letting the video card perform colorspace conversions.

The support for overlays, and the supported colorspaces, is independant from the screenmode. So, you should try all colorspace constants (not just the current video mode one), because overlays are most often used with YUV spaces, and can use a different colorspace from the desktop.

Sorry about this, it should have been part of the task description.

[mmu_man]

Indeed, well the task descriptions said "list" and "colorspaces" with an s ;-)

[hypgci]

I have uploaded a new patch per the above comments.

[hypgci]

Replacing the previous patch file

[hypgci]

I have just replaced previous patch file with the same name.

[rudolfc]

Hi,

I'm sorry, but I have to correct pulkomandy. Actually, the app_server is currently handling overlay capability of videocards quite buggy!

As fas as I saw upto now (it so happens I am working on a overlay engine atm..) the app_server just once asks the driver if overlay is supported. That's wrong.

Furthermore, the app_server asks this question even before the first mode was set. Wrong again. The target mode should be set, and then (only then!) the app_server should request the overlay hooks.

I should open a ticket for this!

Please have a look at the code for the overlay hook exports in the VIA driver and you'll recognize why it should be as I just described (and also how Be did it!)

So, it's entirely valid to check for a certain mode (and colorspace!, but also single/dualhead for instance, or virtual larger space than is visible..) per mode.

Background: higher res modes require more RAM. possibly leaving not enough RAM for overlay. Or: quite possible, for just one offscreen buffer instead of for instance 3..

It's possible 8 bit (indexed) color output space is not supported, while others are.

Probably I can come up with more reasons why the app_server should do it as I described..

Granted, for newer cards there will be less restrictions than for older cards... Still, the way Be did it is the only theoretically correct way!

Oh, Since no mode is set before the hooks are requested, chances are some cards don't export their hooks, as no set colorspace as output space is not supported by definition.

Bye!

Rudolf.

[rudolfc]

Hmm,

One more important item is RAM bandwidth: this is especially an item on higher res modes, with high colorspace, on shared RAM solutions (cheaper videocards, some laptops..):

So, if the total RAM bandwidth used for the mode itself leaves not enough bandwidth for next to that fetching overlay images.. the hooks will, for these modes, not be exported.

Rudolf.

[rudolfc]

Maybe a bit off-topic,

but if you'd write a videoplayer: that player should be aware that after modeswitches the app should fall-back (or upgrade) to bitmap mode (or overlay mode). This also applies if a workspace switch happens (dragging player to other workspace).

Of course the overlay input colorspace can be different from the output space. Mostly YUY2 is supported on our drivers. YCbCr422 like. Hope I have the names right by heart..

Bye!

Rudolf.

[mmu_man]

Indeed, besides bitmaps_support_space() doesn't even take a screen_id, so it can't differentiate either when multicard support will be added.

Anyway, that should be enough for the GCI task, please create a separate ticket for the rest.

[hypgci]

Replaced the previous patch file with the same file name.

[mmu_man]

Pushed as hrev50050, thanks!