Custom Query (16363 matches)
Results (2137 - 2139 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #10894 | fixed | glXBindTexImageEXT is not compliant -> fixed as of 1 Oct 2012 (4.2 and later) | ||
| Description |
glXBindTexImageEXT opens a new X connection on the first time it is invoked when the client may have a server grab. This is not compliant with the specification: http://developer.download.nvidia.com/opengl/specs/GLX_EXT_texture_from_pixmap.txt
This results in a deadlock on startup with recent versions of compiz. A patch to fix this is attached. |
|||
| #11503 | fixed | glx.c in crOpenGL needs to open a second X Connection in order to process damage events -> fixed as of 21 Oct 2013, 4.2 and later | ||
| Description |
This is more of a follow up to https://www.virtualbox.org/ticket/10894 . glx.c in crOpenGL still needs to open up a second X connection in order to process damage events. Processing damage on pixmaps before re-copying them is fine, but using a second X connection in order to fetch the damage is risky because at any point in your library, you could be affected by a server grab in the client process. There is a an issue with just listening for damage on the first connection, because the client might interfere with that. (I've found there are places where compiz may still hang in VirtualBox 4.2.6 because of this). So instead, the best way to handle it is to fetch damage synchronously from the server using XDamageSubtract and XFixesFetchRegion. This doesn't have any impact on performance, because the previous operation was already synchronous as we had to call XSync before fetching damage evnets. I've attached a patch to do that. I've checked that it compiles, however I'm not able to get VirtualBox to install correctly, so I can't verify that it works as expected. However, I've written similar code in the past, so I'm 90% sure it should work. (At the moment we're just working around this in compiz itself, but that's ugly because we had to do things like detect drivers). |
|||
| #811 | obsolete | USB working incompletely (GSM tools) | ||
| Description |
I have many USB hardware for GSM programming like UFS, JAF boxes, smart-card readers etc. All hardware can be detected on USB okay, but some hardware like smart-card readers working, but the most important UFS box is not. UFS' leds is blinking when it accessed, but then software prints "communication error". Nokia PC suite is not working too if the phone on USB. Some Siemens FFS-init software (working on PL-2303 usb-to-com cable) work but very unstable, can lose the phone half-programmed. May be there is some timing-problems with USB... I don't know. Tell me if you need any logs or details. |
|||

