Opened 9 years ago

Closed 9 years ago

#12611 closed enhancement (fixed)

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

Reported by: hypgci Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Applications/Command Line Tools Version: R1/Development
Keywords: GCI Cc:
Blocked By: Blocking:
Platform: All

Description

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

Attachments (3)

0001-also-print-color-space-and-overlay-support-status.patch (1.3 KB ) - added by hypgci 9 years ago.
0001-also-print-all-supported-bitmap-overlay-colorspaces.patch (3.4 KB ) - added by hypgci 9 years ago.
Replacing the previous patch file
0001-screeninfo-also-print-all-supported-bitmap-overlay-c.patch (1.9 KB ) - added by hypgci 9 years ago.
Replaced the previous patch file with the same file name.

Download all attachments as: .zip

Change History (13)

comment:1 by hypgci, 9 years ago

patch: 01

comment:2 by pulkomandy, 9 years ago

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, I would do things like this:

  • screenmode (no options) shows the current screenmode. No changes here.
  • screenmode -l lists available modes. Again, no changes
  • screenmode -o lists available overlay colorspaces. It should try all colorspace constants (not just the 3 you have in the code), because overlays are most often used with YUV spaces.

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

Version 0, edited 9 years ago by pulkomandy (next)

comment:3 by mmu_man, 9 years ago

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

comment:4 by hypgci, 9 years ago

I have uploaded a new patch per the above comments.

by hypgci, 9 years ago

Replacing the previous patch file

comment:5 by hypgci, 9 years ago

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

comment:6 by rudolfc, 9 years ago

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.

comment:7 by rudolfc, 9 years ago

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.

comment:8 by rudolfc, 9 years ago

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.

comment:9 by mmu_man, 9 years ago

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.

by hypgci, 9 years ago

Replaced the previous patch file with the same file name.

comment:10 by mmu_man, 9 years ago

Resolution: fixed
Status: newclosed

Pushed as hrev50050, thanks!

Note: See TracTickets for help on using tickets.