id summary reporter owner description type status priority milestone component version resolution keywords cc blockedby blocking platform 12613 app_server handles overlay hooks incorrectly. rudolfc axeld "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. " bug new normal Unscheduled Servers/app_server R1/Development overlay setmode All