app_server handles overlay hooks incorrectly.

[rudolfc]

The app_server is currently handling overlay capability of videocards quite buggy.

As fas as I saw upto now (while working on the VIA overlay engine) the app_server just once asks the driver if overlay is supported (directly after system boot). That's wrong. Furthermore, the app_server asks this question even before the first mode was set. Also wrong. The target mode should be set, and then (only then!) the app_server should request the overlay hooks. If a new mode is set, the hooks need to be requested again.

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

Background:

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

There are more restrictions depending on hardware..

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. (check restrictions per mode)

Also: Since no mode is set before the hooks are requested, chances are some cards drivers don't export their hooks, as no set mode is not supported by definition. Even if they do export the hooks, overlay is not guaranteed to work correctly since the driver does not know if the mode will violate it's hardware properties.

At least the VIA driver blocks the hooks (which is correct) because of this.

[rudolfc]

Hi,

By the way, I saw that the last set mode is buffered over system restarts. Also the app_server apparantly buffers the overlay hooks, also over restarts.

The driver won't export the hook on first system start probably, because there was no mode set before and for instance the 'old' colorspace in the 'previously saved mode' will be zero.

Once the driver does export them (second boot probably), the app_server caches these hooks. Currently it does not matter what the driver tries to 'tell' the app_server after that (by not exporting hooks if requested because overlay in a specific mode would not be supported), since the app_server now uses the cached hooks to illegally start overlay.

Of course, that's not meant to be as I explained in the ticket description.

Rudolf.

[rudolfc]

Hello,

I've got another problem for app_Server:

• hardware overlay works with something called a 'magic color'. This is used to tell the hardware to show (part of) the overlay image, or show (part of) the desktop.

Because of this, care should be taken in choosing this magic color: it should be a color normally -not- used on desktops and apps. Otherwise, overlay will 'leak' through at points where this color is used.

And, currently, black is choosen as magic color.. that's a big no-no as you can imagine!

I'll get back on CMAP8 desktops: seems like the magic color choosen is not in the palette there: hence overlay with color-keying (as this feature is called) does not work there (tested on VIA driver)

Rudolf.

[axeld]

The app_server doesn't use black, or at least didn't use to; I definitely were able to run Haiku with overlay just fine some years ago with the Intel Extreme driver (which also worked in BeOS).

Anyway, the following code determines the color: ​http://xref.plausible.coop/source/xref/haiku/src/servers/app/drawing/Overlay.cpp#70

I can only say that this used to work -- it might have been broken in the mean time, but I don't believe it until proven :-)

The CMAP8 issue might actually be a real issue, though; I don't remember if I ever tested that, at least.

[axeld]

Also, no hooks are preserved between system restarts -- how would that work, anyway? The hooks are queried only once on init, which is apparently wrong for some hooks, but easily changed. I'll try to fix that particular issue tomorrow.

[rudolfc]

Good morning Axel!,

Well, since I check the accelerant log, I can see that the driver tells the app_server it may -not- use the overlay hooks (because it's requested -before- a modeswitch): still I get overlay video. that should be impossible unless the app_server had the hooks already.

About the magic color: I'll check a bit more as far as I can do.. still: would a mediaplayer be able to show me overlay video if it did not get the color from app_server? (don't know by heart atm how this mechanism works exactly.. )

Bye!

Rudolf.

[rudolfc]

Oh, from the via.acccelerant.0.log after a system start:

Overlay: Invalid colour depth 0x00000000 Overlay: Not exporting hook B_OVERLAY_COUNT. Overlay: Invalid colour depth 0x00000000 Overlay: Not exporting hook B_OVERLAY_SUPPORTED_SPACES. Overlay: Invalid colour depth 0x00000000 Overlay: Not exporting hook B_OVERLAY_SUPPORTED_FEATURES. Overlay: Invalid colour depth 0x00000000 Overlay: Not exporting hook B_ALLOCATE_OVERLAY_BUFFER. Overlay: Invalid colour depth 0x00000000 Overlay: Not exporting hook B_RELEASE_OVERLAY_BUFFER. Overlay: Invalid colour depth 0x00000000 Overlay: Not exporting hook B_GET_OVERLAY_CONSTRAINTS. Overlay: Invalid colour depth 0x00000000 Overlay: Not exporting hook B_ALLOCATE_OVERLAY. Overlay: Invalid colour depth 0x00000000 Overlay: Not exporting hook B_RELEASE_OVERLAY. Overlay: Invalid colour depth 0x00000000 Overlay: Not exporting hook B_CONFIGURE_OVERLAY. SETMODE: (ENTER) initial modeflags: $8000001f SETMODE: requested target pixelclock 64996kHz SETMODE: requested virtual_width 1024, virtual_height 768

This setmode command at the end is the first mode set by the app_server using the driver. After this particular boot I could start VLC 0.86D and enjoy overlay..

Of course I could prevent that by just extra blocking the overlay functions if not officially 'released', but these should not have been called in the first place.

Rudolf.

[rudolfc]

Axel,

I stand corrected! I see I always return B_OK on get hooks :-/ (sorry) I'll fix that asap. That leaves magic color and asking for the hooks.. (which should be after each setmode instead of only once before the first setmode)

Bye!

Rudolf.

[rudolfc]

Hi,

Blocking overlay hooks is fixed from hrev50059 on. Checked the nVidia, Matrox and Neomagic driver as well: these were OK already.

Bye!

Rudolf.

[axeld]

I've fixed the app_server to update the overlay hooks after each mode change in hrev50063. However, I could not test the changes on a system that actually supports overlay.

BTW: there is no need to add a "Hi", and "Bye" line on Trac -- it just makes the comments unnecessary longer, and thus makes the ticket harder to read. Your name is already in the header of any comment, anyway :-)

[rudolfc]

The overlay hooks are indeed requested after every mode switch now. Still got to check the magic color thing. Though I am having trouble replacing just the app_server after recompile: would that work outside of the package system? Costing lots of time testing atm..

[axeld]

The app_server is nowadays started by the launch_daemon by this service description (part of /system/data/launch/system):

service x-vnd.Haiku-app_server {
    launch /system/servers/app_server
}

You should be able to override that service by placing a settings file into /system/settings/launch/ that contains more or less the following:

service x-vnd.Haiku-app_server {
    launch /path/to/the/new/app_server
}

[rudolfc]

OK will try that, thanks. The problem with the overlay color is two-fold: first, in Overlay::SetColorSpace(uint32 colorSpace) for CMAP 8 the previously set color is hard-overwritten with white ($FFFFFF). The other is that the key chosen (for all intends and purposes black after all) is a bad one: you have to realize that for 15 and 16 bit spaces the lower bits are shifted-out, which means the exact color gets lost. App_server should chose a color which has the lower 3 bits reset at all times _and_ it has to exist in the CMAP8 indexed color map. Also it has to be a color rarely used.. Dano uses purple, and I now know why: when I search the CMAP8 options, this is the one and only color (more or less?) that fits the description I just did: set R=152, G=0, B=152. That will work OK.

I'll test this momentarily I hope.. (ok, later, cant get app_server running seperately :-/)

Will you update app_Server for this if it works Axel?

[AlienSoldier]

rudolfc, as you play in overlay land lately, maybe you could check into ticket 9917. I still don't have overlay in media player with hrev5009 btw.

[rudolfc]

Aliensoldier, that's because mediaplayer internally does not (translate to) the one and only colorspace supported by most of our drivers for overlay (B_YCbCr422), unfornunately :-/

[rudolfc]

Axel, Can a point at a naked app_server executable or do I have to put it inside a .hpkg or so? Tried two versions of Haiku and both don't start app_server succesfully. So the settings file seems to work, but loading app_server would seem to fail. Any more hints? BTW You can apply the changes I proposed, that really should fix the problems I see.

[axeld]

Putting it in a HPKG won't work; only the package file system knows about those. All you have to make sure is that the executable is on a place that is mounted during early boot, ie. it pretty much has to be on the boot volume.

About the color: I chose that almost black color because as a user, a color like Dano's pink will look very bad :-) I'm pretty sure they only chose that for debugging reasons, anyway. IIRC other platforms used some green color tone.

I guess there is no reason to use different colors for different color spaces, now is there? Anyway, do you have a less "intriguing" color ready that we can use? :-)

[rudolfc]

Ah, then it must be the folder I got wrong :-) I'll try again. About the color: that's exactly the point! no-one will use it since it's so 'ugly'. You have to realize that you will never see this color as it will be surpressed by the overlay engine outputting video.

Ok, maybe during resizing you would momentarily see it around the video borders if you do heavy logging in the driver or so.. If that's a problem then you're right: we should choose a less intrusive color then. Indeed there's no need to use different colors for different spaces, unless you choose a color that's outside of the current mode's 'scope'.

If you want another color but still a rarely used one, we will have to add that color to the palette in CMAP8: which means another has to go.. Would you have a suggestion for a specific color that can be gone in CMAP8 so we can replace that one?

[axeld]

Yes, the color "leaks" through on heavy window movement, that's why I would want to have a less obtrusive color. It only has to be a color that is rarely used in the UI; you cannot really anticipate a use of colors in pictures.

Anyway, yes, some CMAP8 color would need to go, but since everyone faced the same problem, I would assume that someone (in this case Be) already solved that for us, at least in case we're using the same palette.

[rudolfc]

I'll have a look for an option in the existing palette. Btw,in theory appserver does nog neer tot anticipatie because the magic color van be set per picture buffer, so if a color gets used it could switch tot another color. With a speed penalty though of course. Correct me if i'm wrong..

[rudolfc]

Axel, how about using R=0, G=80, B=0? that's dark-green, and in the CMAP8 map. Hopefully not much used.. Or, pick any greyscale from this map (8,8,8 or 16,16,16...etc). Again hopefully not much used.. There are no other choices from the current map I think. If one could be replaced, a less obvious color could be picked, like 8,16,24 (or combined otherwise). If you want it to not be visible much, it should be in the low numbers of course, and each number always be dividable by 8. If we pick a color we use in all spaces that is. I would not know which color could be gone.. I guess it would be a color that would be replaced by a nearing one: but that seems not possible if I look at the current map. So, which color is not used in practice? I would not know the answer to that one.. I'd say just pick the 0,80,0 color or a low greyscale one (16,16,16?). We can always change it again in the future. OK?

[rudolfc]

Updated app_server for suggested fixes in hrev50119. If I'm stepping out of bounds, let me know :)

[rudolfc]

Problem fixed. Overlay works in all colorspaces without 'character leaking'. Closing ticket.

[axeld]

Thanks, Rudolf, it's appreciated!