> I think the intel driver forces a reset to the system scanout on release. I've
> actually never found a test to indicate it was completely necessary on
> other GPUs
I need to force this on the GMA500 because we want some kind of sane
scanout left and the nice guys at Dell decided the Mini 10 did
> I think the intel driver forces a reset to the system scanout on release. I've
> actually never found a test to indicate it was completely necessary on
> other GPUs
I need to force this on the GMA500 because we want some kind of sane
scanout left and the nice guys at Dell decided the Mini 10 did
On Fri, Jun 3, 2011 at 4:37 AM, Alan Cox wrote:
> I have GEM allocation working on the GMA 500 and I can scribble in a
> framebuffer (minus an odd 'last page' bug which is an off by one
> somewhere I imagine) and display it with nice modetest stripes.
>
> If I kill the program however it all goes
On Fri, Jun 3, 2011 at 4:37 AM, Alan Cox wrote:
> I have GEM allocation working on the GMA 500 and I can scribble in a
> framebuffer (minus an odd 'last page' bug which is an off by one
> somewhere I imagine) and display it with nice modetest stripes.
>
> If I kill the program however it all goes
I have GEM allocation working on the GMA 500 and I can scribble in a
framebuffer (minus an odd 'last page' bug which is an off by one
somewhere I imagine) and display it with nice modetest stripes.
If I kill the program however it all goes kerblam
drm_release calls into fb_release which duely des
I have GEM allocation working on the GMA 500 and I can scribble in a
framebuffer (minus an odd 'last page' bug which is an off by one
somewhere I imagine) and display it with nice modetest stripes.
If I kill the program however it all goes kerblam
drm_release calls into fb_release which duely des
