On 2017-06-15 12:15, Boris Brezillon wrote: > On Thu, 15 Jun 2017 11:54:29 +0200 > Peter Rosin <peda@xxxxxxxxxx> wrote: > >> On 2017-06-13 17:30, Boris Brezillon wrote: >>> Hi Peter, >>> >>> On Tue, 13 Jun 2017 16:34:25 +0200 >>> Peter Rosin <peda@xxxxxxxxxx> wrote: >>> >>>> Hi! >>>> >>>> I need color lookup support for the atmel-hlcdc driver, and had a peek >>>> at the code. I also looked at the drivers/gpu/drm/stm driver and came >>>> up with the below diff. It compiles, but I have not booted it for the >>>> simple reason that I can't imagine it will work. >>>> >>>> Sure, the code fills the clut registers in the .load_lut helper function >>>> and I think it might even do the right thing when setting up the mode. >>>> I'm less sure DMA will work correctly? It might, but I haven't looked at >>>> it for many seconds... >>>> >>>> The big question is how the color info gets into the new clut array >>>> I created in atmel_hlcdc_crtc? When I look at the stm driver, which does >>>> it just like this AFAICT I just don't see it. So, what I'm I missing? >>> >>> You should look at drm_atomic_helper_legacy_gamma_set() and its users. >> >> Ok, thanks. I had a long look and could not get it to work at all. > > Probably because you're trying to set this up through the emulated > fbdev interface. The solution I proposed is supposed to be accessed > through DRM ioctls. Yes, that seems like the root cause of most of my troubles. But, the apps I have seem to use the fbdev interface, and if the emulation is poorly done, they won't work right... >> So, >> I did as below instead. However, there are a few glaring problems... > > Well, I doubt this will be accepted. The fbdev emulation layer is > supposed to be rather dumb, partly because DRM people want developers > to switch to the DRM interface. Sigh. > Also note that I won't accept a solution that supports setting the LUT > table only through the fbdev interface, so please try to make it work > the DRM way before you even consider modifying the fbdev emulation > layer. Ok, I'll have another look. But to me, it's a maze... >> >> Something, somewhere, sets up default entries for the 16 first entries >> of the palette and seem to expect them to stay as some kind of safe >> basic palette, and my applications don't handle it too well. When they >> want to draw black, they get a poisonous cyan/green instead etc. But >> it's pretty close. Can anyone provide some clue as to how that is >> supposed to be handled? >> >> Also, I had to change the second argument of the drm_fbdev_cma_init... >> call at the end of atmel_hlcdc_dc.c:atmel_hlcdc_dc_load() from 24 to 8 >> to make it possible to set 8-modes. However, doing so fucks up 24-bit >> modes. Which made me suspect that no non-24-bit mode work w/o my patch. >> And I could indeed only get 24-bit modes to work, unless I changed this >> value to 16. Then RGB565 works like a charm, but RGB888 don't. What's >> up with that? Seems like a rather silly limitation, but it's perhaps >> just a bug? > > I'm pretty sure this is not a bug. AFAIR, prefered_bpp is used when you > don't explicitly specify the video mode you want to use on the cmdline > [1]. > > [1]http://elixir.free-electrons.com/linux/v3.11/source/Documentation/fb/modedb.txt > (Why refer to v3.11 docs?) Let's start with some basics, I tried to add video=atmel-hclcd-dc:1024x768-16 and video=atmel_hclcd_dc:1024x768-16 to the kernel cmdline of an unpatched linux-next kernel. No dice, I can still only access RBG888. I'm obviously in need of some hand-holding... How am I supposed to get a 16-bit mode? Cheers, peda _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
