# not sure why this was here tag 390287 - patch thanks pushling provided me with another strace, of the case where xawtv was functioning (with the symlink in place, as described above); the strace is attached.
When comparing it to the strace of the failing xawtv, it turns out that
in the strace for the _working_ process, /dev/dri/card0 can't be
openened correctly (probably because it is not a proper dri device).
Because of this, libGL falls back to some other, slower rendering of the
tv image:
| stat64("/dev/dri/card0", {st_mode=S_IFCHR|0660, st_rdev=makedev(81, 0), ...})
= 0
| open("/dev/dri/card0", O_RDWR) = 4
| ioctl(4, DECODER_SET_PICTURE, 0xbfeaca50) = -1 EINVAL (Invalid argument)
| ioctl(4, DECODER_GET_CAPABILITIES, 0xbfeaca54) = -1 EINVAL (Invalid argument)
| close(4) = 0
...
| write(2, "libGL error: open DRM failed (Op"..., 55) = 55
| write(2, "libGL error: reverting to (slow)"..., 52) = 52
The strace of the non-fucntioning xawtv, otoh, shows that /dev/dri/card0
is opened correctly, and linGL tries to use it to show the video. In
the end of the strace, it seems some ioctl on that device fails:
| ioctl(4, 0x4008642a, 0xbff16824) = ? ERESTARTSYS (To be restarted)
So, I'm guessing that this is either a bug in the reporter's GL/dri
setup, or a bug in OpenGL.
--
+--------------------------------------------------------------------+
| Bas Zoetekouw | GPG key: 0644fab7 |
|----------------------------| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 |
+--------------------------------------------------------------------+
xawtv.working.strace.gz
Description: Binary data
