On Thu, 15 Jun 2017 13:47:35 +0200 Peter Rosin <peda@xxxxxxxxxx> wrote: > 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? You should have a look at [1]. [1]https://www.at91.com/linux4sam/bin/view/Linux4SAM/UsingAtmelDRMDriver#Choose_supported_modes _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
