Green artefacts with XFree 4.3/4.4 + Xv + Intel865GBF: Xv bug ??
Hi list ! I'm developping an application which displays video using Xv and allow user to interact with it using Qt. Some Qt graphical items are drawn on top of the video while playing, using overlay. Until now my linux system was using an ATI radeon 9700 graphic card and I've got no problem. But recently I migrate my system to an intel 865GBF motherboard with integrated graphic chip (I don't use the ATI card anymore). I now have sometimes green artefacts/lines on the graphical zone shared by Xv and Qt/X11. :-( These artefacts occur randomly but if I got them one time, they are persistent until I close my application. I can reduce their occurance by setting VideoRam to 16384 (same value as the one set in my BIOS for frame buffer size) in my XF86Config-4 file. If I use 65535 as VideoRam value or if I desactivate DRI, then these green artefacts are more likely to appear... So far, I've tried XFree 4.3 4.4, linux kernel 2.4 and 2.6 always the same problems !!! Is there someone here to help me or who has already had the same problem ? Thanks a lot !! Julien ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
2.6.9-rc1 linux/fb.h (was: cvs compile failed: fbdev)
On Mon, 6 Sep 2004, Marc Aurele La France wrote: On Mon, 6 Sep 2004, Michael Lampe wrote: Marc Aurele La France wrote: ... In both cases, this is a kernel issue. They will tell you it's not: /usr/include/linux/list.h:700: warning: #warning don't include kernel headers in userspace Irrelevant. The #include linux/list.h is only there in an attempt to resolve the type of the inserted kernel memory list pointer. I don't know how to handle this properly, though. Don't assume problems with test kernels need to be resolved here. You didn't get it. Including linux kernel headers in user space is a no no. See various threads about this on LKML. Bottom line: If you include kernel headers and your app breaks it's your fault not ours. Leave religion out of this. 1) Xfbdev has always been Linux-specific. 2) Driving /dev/fb* as anything other than a dumb framebuffer isn't possible without linux/fb.h's ioctl's. rc1 is broken WRT this problem. Fix this there. Now that I have more time to deal with this issue, let's recap/clarify: I agree with you that asm/ headers should normally not be #include'd by apps. I also think allowing (forcing, in this case) userland to #include linux/list.h sets a dangerous precedent. But this is about 2.6.9-rc1's linux/fb.h, a header that provides ioctl's (userland stuff) and therefore disallowing its use from userland is not an option. It turns out that the fb_monspecs structure modified by rc1 is not ioctl-visible. Thus to fix this problem, it should be sufficient to bracket the fb_manspecs fb_chroma structure definitions and the #include linux/list.h with __KERNEL__, which is what the attached patch against rc1 does. This also deletes a duplicate function declaration in linux/fb.h. I am cc'ing this to those who vouched for the problem change to be included in rc1. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. fb.diff.gz Description: Binary data
Re: 2.6.9-rc1 linux/fb.h (was: cvs compile failed: fbdev)
Marc Aurele La France [EMAIL PROTECTED] wrote: [fb.diff.gz APPLICATION/octet-stream (1178 bytes)] gack, please send patches as inline text or, if you must, text/plain attachments. Tony, could you please process this one, send it back at us? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 2.6.9-rc1 linux/fb.h (was: cvs compile failed: fbdev)
On Friday 10 September 2004 03:11, Andrew Morton wrote: Marc Aurele La France [EMAIL PROTECTED] wrote: [fb.diff.gz APPLICATION/octet-stream (1178 bytes)] gack, please send patches as inline text or, if you must, text/plain attachments. Tony, could you please process this one, send it back at us? Actually, someone might have planned to expose struct fb_monspecs to userspace, the ioctls are present but commented, probably the reason why this structure is not enclosed in an #ifdef __KERNEL__. /* #define FBIOGET_MONITORSPEC 0x460C */ /* #define FBIOPUT_MONITORSPEC 0x460D */ Anyway, someone already reported this to the fbdev-devel list and I agreed to fix this by moving struct list_head modelist out of struct fb_monspecs instead. Will submit a patch soon enough. Tony ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
