[Letux-kernel] DSI & DPI panels with omapdrm on 4.20-rc
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Fri Nov 23 15:07:26 CET 2018
Hi Nikolaus,
On Friday, 16 November 2018 21:10:17 EET H. Nikolaus Schaller wrote:
> Am 16.11.2018 um 13:46 schrieb Tomi Valkeinen <tomi.valkeinen at ti.com>:
> > On 15/11/18 17:50, H. Nikolaus Schaller wrote:
> >> Am 15.11.2018 um 12:17 schrieb Tomi Valkeinen:
> >>> On 15/11/18 08:00, H. Nikolaus Schaller wrote:
> >>>> But also DISPC_POL_FREQ.
> >>>
> >>> Can you try the attached hack patch?
> >>
> >> Seems to fix something. I now have a desktop back on the panel :)
> >
> > Ok. I need to discuss with Laurent about this when he gets back.
> >
> >> What I have observed is that the panel dimensions in mm seem to have
> >> changed (because our GUI software uses that as a scaling factor).
> >
> > Which panel driver is this? Does "changed" mean that they were correct
> > previously, and not anymore? What are/were the numbers?
>
> It turned out that
>
> xdpyinfo | grep dimensions
>
> did report different dimensions in mm than specified in xorg.conf.
> But only for my dpi-panel based device variant.
>
> But see below.
>
> >> When reworking the dsi panel drivers, I have seen that panel drivers
> >> can now report the dimensions in mm. So does the generic DPI driver have
> >> a new default here? Can it be specified by new DT properties?
> >> But I have to check that I do not have a user-space bug here.
> >
> > panel-dpi.c has not and does not supported physical size. There's code
> > in omap_connector.c that calls get_size() to get the size. You could add
> > debug prints there to see if it's called and what are the numbers.
>
> When updating the dsi panel drivers, I was misguided to conclude by
>
> https://elixir.bootlin.com/linux/v4.20-rc1/source/drivers/gpu/drm/omapdrm/d
> isplays/panel-dsi-cm.c#L1173
>
> to think that all omapdrm panel drivers use that...
>
> >> How does omapdrm X11 handle the mouse cursor? By an overlay of the
> >> OMAP3 DSS? Then there may be some other bits for the overlay priority
> >> depend on driver probe sequence (the td028ttec1 is probed as an SPI
> >> client, probably before omapdrm but I don't know).
> >
> > If I recall right, omap xdriver has a config option for HW or SW cursor,
> > and HW cursor uses a plane with legacy modesetting to show the cursor.
> > HW cursor has always been buggy, but apparently something has changed,
> > causing the plane not to be transparent.
>
> I have found the issue and it is not the panel driver or kernel.
>
> There weren't many differences and I even swapped the SD card between both
> devices. Still they did scale differently and the cursor had the black
> background on the dpi-panel device.
>
> The only differences (besides the different panel hardware connected to
> omap3) are * u-boot (to load different DTB files)
> * panel driver
> * xorg.conf (switched automatically based on /proc/device-tree/model string)
>
> After doing more testing it turned out that the xorg.conf were not doing
> things the same way.
>
> The scaling issue was a bad entry in the Monitor property of a Screen
> section. So it appears that it tried to use some tv dimensions or something
> else. Setting Monitor "lcd" did fix it.
>
> The cursor background issue could be solved by using
>
> Option "HWcursor" "False"
>
> for all panels and not only the td028ttec1...
>
> BR and thanks and sorry for the noise with non-kernel issues,
No need to be sorry. I'm sorry for breaking panel-dpi in the first place.
Thank you for reporting the issue and helping debugging it. Your efforts are
really appreciated.
--
Regards,
Laurent Pinchart
More information about the Letux-kernel
mailing list