On Mon, Oct 3, 2011 at 3:37 PM, James Simmons <jsimmons@xxxxxxxxxxxxx> wrote: > >> > Hi! >> > >> > I been working on updating the VIA kernel driver to using KMS >> > and TTM. So this weekend I started to implement a couple of buffer >> > allocations internally to the driver from the video ram. So the first >> > buffer I allocated was not the front buffer from the video vram but a >> > virtual queue buffer of about 256K in size. The second allocation was >> > the front buffer. The problem was the buffer offset for the second >> > allocation was the same as the VQ buffer. I'm stump to what I'm doing >> > wrong, so does anyone have a idea? >> >> Without code to look at we all can start guessing :) my guess is either >> you are not using the proper offset field or you are allocating from >> different memory pool. > > http://cgit.freedesktop.org/~jsimmons/drm-openchrome > >From quick glimpse ttm_bo_allocate in via/init_ttm.c loose the TTM_PL_FLAG_NO_EVICT so you vq buffer is not allocated with the no evict flags, then i guess it got evicted on first bo allocation which is strange, maybe first bo has some lpfn constraint. >> > Second question I have is how are monochrome cursor images >> > handled with KMS. Yes we need to support CLE266 which is used in a lot >> > of POS devices. That chipset only supports monochrome cursors. >> >> You can hide the cursor limitation from userspace and pretend supporting >> rgb cursor. > > So just return -ENXIO in that case. No, so far there is no format specification for cursor, so userspace can send monochrome or you can accept rgb from userspace and convert to monochrome inside the kernel, but i think it's better to just assume userspace sends you monochrome. Cheers, Jerome _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
