Hello,
I have now ported the driver to exa_mixed (also because the exa_classic bugfix
is not being backported to 1.7 and this way we bypass the issue).
Driver seems to work fine, just like it did under exa_classic.
But the same issue remains, mplayer and others still use the fullscreen pixmap
On Don, 2010-07-22 at 20:18 +0200, Yves De Muyter wrote:
I have now ported the driver to exa_mixed (also because the
exa_classic bugfix is not being backported to 1.7 and this way we
bypass the issue).
Driver seems to work fine, just like it did under exa_classic.
But the same issue
Second argument of fbScreenInit() is definitely not NULL but points to
the framebuffer address like it should.
I have been debugging some more. It looks like pExaPixmap-fb_ptr is
NULL, and in exaGetPixmapOffset() it returns fb_ptr - memoryBase without
ever checking fb_ptr resulting in a (0 -
On Fre, 2010-07-23 at 12:07 +0200, Yves De Muyter wrote:
Second argument of fbScreenInit() is definitely not NULL but points to
the framebuffer address like it should.
Again, you need to pass NULL to prevent the screen pixmap from being
pinned in system memory.
--
Earthling Michel Dänzer
On Fre, 2010-07-23 at 14:30 +0200, Yves De Muyter wrote:
Sorry I misread your suggestion.
No worries, my bad for using double negation.
I now pass NULL as second argument to fbScreenInit(). Driver seems to
work fine on non-Xv stuff so that seems fine.
I'm not so sure the current issue
Sorry I misread your suggestion. I now pass NULL as second argument to
fbScreenInit(). Driver seems to work fine on non-Xv stuff so that seems
fine.
I'm not so sure the current issue is still with the pixmap being pinned
nor that it is the screen pixmap. The fb_ptr on the pixmap is still
NULL,
Hello,
I have now ported the driver to exa_mixed (also because the exa_classic bugfix
is not being backported to 1.7 and this way we bypass the issue).
Driver seems to work fine, just like it did under exa_classic.
But the same issue remains, mplayer and others still use the fullscreen pixmap
OK so i'm porting the 'poulsbo' driver to Xorg 1.7. What I'm working on
right now is to make Xv work in the driver. What the Xv-code does is to
get the address of the drawable, map it into SHM and ask the hardware to
blit the videoframe onto that drawable.
The problem is that the address of the
Here you find the code:
http://code.google.com/p/gma500/source/browse/trunk/xserver-xorg-video-psb/xserver-xorg-video-psb-0.32.1/src/psb_video.c
The problem is on line 688.
The code tries to find the pointer to the buffer and the offset, and if
it doesnt find it, it calls exaMoveInPixmap().
I
On Don, 2010-06-10 at 12:54 +0200, Yves De Muyter wrote:
Here you find the code:
http://code.google.com/p/gma500/source/browse/trunk/xserver-xorg-video-psb/xserver-xorg-video-psb-0.32.1/src/psb_video.c
The problem is on line 688.
The code tries to find the pointer to the buffer and the
On Thu, Jun 10, 2010 at 8:56 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
2010/6/10 Yves De Muyter y...@alfavisio.be:
Is there any documentation available about the differences between
exa_mixed and exa_driver ? Is exa_driver like complete handover of
pixmap migration to the driver ?
11 matches
Mail list logo
