Revert "video: fbdev: mxsfb: Remove driver"

Revert "video: fbdev: mxsfb: Remove driver"

[Alistair Francis]

Hello,

Commit f225f1393f034 "video: fbdev: mxsfb: Remove driver" removed the
mxsfb fbdev driver.

I am now working on getting mainline Linux running on the reMarkable 2
eInk reader [1]. Unfortunately the rM2 doesn't use the standard EPD
controller on the i.MX SoC, but instead uses the LCD controller.

eInk panels are complex to control and require writing temperature
dependent waveforms. As these waveforms are proprietary [2] the rM
team runs closed source software called SWTCON in userspace to control
the panel [3].

This closed source software expects the fbdev mxsfb driver and it
doesn't work with the DRM mxsfb driver (at least not that I can get it
to).

The NXP fork of Linux also re-adds the fbdev driver [4], so they also
see some uses for it.

I was wondering if the community would be open to re-adding the fbdev
mxsfb driver to mainline? It could be re-added with a different
dt-binding so that it is not used by default and only enabled for
boards when required (like for the rM2).

1: https://remarkable.com/store/remarkable-2
2: https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-closely-guarded-secret
3: https://remarkablewiki.com/tech/rm2_framebuffer
4: https://source.codeaurora.org/external/imx/linux-imx/log/drivers/video/fbdev/mxsfb.c?h=lf-5.10.35-2.0.0

Alistair

Re: Revert "video: fbdev: mxsfb: Remove driver"

[Marek Vasut]

On 8/15/21 2:16 PM, Alistair Francis wrote:
> Hello,
> 
> Commit f225f1393f034 "video: fbdev: mxsfb: Remove driver" removed the
> mxsfb fbdev driver.
> 
> I am now working on getting mainline Linux running on the reMarkable 2
> eInk reader [1]. Unfortunately the rM2 doesn't use the standard EPD
> controller on the i.MX SoC, but instead uses the LCD controller.
> 
> eInk panels are complex to control and require writing temperature
> dependent waveforms. As these waveforms are proprietary [2] the rM
> team runs closed source software called SWTCON in userspace to control
> the panel [3].
> 
> This closed source software expects the fbdev mxsfb driver and it
> doesn't work with the DRM mxsfb driver (at least not that I can get it
> to).
> 
> The NXP fork of Linux also re-adds the fbdev driver [4], so they also
> see some uses for it.
> 
> I was wondering if the community would be open to re-adding the fbdev
> mxsfb driver to mainline? It could be re-added with a different
> dt-binding so that it is not used by default and only enabled for
> boards when required (like for the rM2).
> 
> 1: https://remarkable.com/store/remarkable-2
> 2: https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-closely-guarded-secret
> 3: https://remarkablewiki.com/tech/rm2_framebuffer
> 4: https://source.codeaurora.org/external/imx/linux-imx/log/drivers/video/fbdev/mxsfb.c?h=lf-5.10.35-2.0.0

+CC Sam.

What sort of special thing does your proprietary userspace do that 
cannot be added to the DRM driver or the fbdev emulation (if needed) ?

Re: Revert "video: fbdev: mxsfb: Remove driver"

[Alistair Francis]

On Sun, Aug 15, 2021 at 10:31 PM Marek Vasut <marex@denx.de> wrote:
>
> On 8/15/21 2:16 PM, Alistair Francis wrote:
> > Hello,
> >
> > Commit f225f1393f034 "video: fbdev: mxsfb: Remove driver" removed the
> > mxsfb fbdev driver.
> >
> > I am now working on getting mainline Linux running on the reMarkable 2
> > eInk reader [1]. Unfortunately the rM2 doesn't use the standard EPD
> > controller on the i.MX SoC, but instead uses the LCD controller.
> >
> > eInk panels are complex to control and require writing temperature
> > dependent waveforms. As these waveforms are proprietary [2] the rM
> > team runs closed source software called SWTCON in userspace to control
> > the panel [3].
> >
> > This closed source software expects the fbdev mxsfb driver and it
> > doesn't work with the DRM mxsfb driver (at least not that I can get it
> > to).
> >
> > The NXP fork of Linux also re-adds the fbdev driver [4], so they also
> > see some uses for it.
> >
> > I was wondering if the community would be open to re-adding the fbdev
> > mxsfb driver to mainline? It could be re-added with a different
> > dt-binding so that it is not used by default and only enabled for
> > boards when required (like for the rM2).
> >
> > 1: https://remarkable.com/store/remarkable-2
> > 2: https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-closely-guarded-secret
> > 3: https://remarkablewiki.com/tech/rm2_framebuffer
> > 4: https://source.codeaurora.org/external/imx/linux-imx/log/drivers/video/fbdev/mxsfb.c?h=lf-5.10.35-2.0.0
>
> +CC Sam.
>
> What sort of special thing does your proprietary userspace do that
> cannot be added to the DRM driver or the fbdev emulation (if needed) ?

It's hard to tell. When using the DRM driver I get cryptic errors
about the frame buffer not being available. It's difficult to know
what is going on as I don't have access to any of the source. I
suspect the userspace code could be updated to use the DRM driver, but
we would need the reMarkable devs to do that.

There is some effort to re-implement the proprietary user space swtcon
(https://github.com/timower/rM2-stuff#swtcon), but it seems to have
stalled. It wouldn't be impossible to get swtcon to work with the DRM
driver, but it would require a very large amount of reverse
engineering, that probably will never happen.

I wanted to see what the thoughts were on re-adding the fbdev mxsfb
driver. The commit message just says that because there is a DRM
driver we no longer need the fbdev one, but here is a case for the
fbdev driver. I was thinking that continuing to support the fbdev
mxsfb driver wouldn't be too much of a maintenance burden (but that's
obviously up to you). The NXP tree also seems to think the fbdev
driver is worth keeping around.

Alistair

Re: Revert "video: fbdev: mxsfb: Remove driver"

[Marek Vasut]

On 8/16/21 9:34 AM, Alistair Francis wrote:
> On Sun, Aug 15, 2021 at 10:31 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 8/15/21 2:16 PM, Alistair Francis wrote:
>>> Hello,
>>>
>>> Commit f225f1393f034 "video: fbdev: mxsfb: Remove driver" removed the
>>> mxsfb fbdev driver.
>>>
>>> I am now working on getting mainline Linux running on the reMarkable 2
>>> eInk reader [1]. Unfortunately the rM2 doesn't use the standard EPD
>>> controller on the i.MX SoC, but instead uses the LCD controller.
>>>
>>> eInk panels are complex to control and require writing temperature
>>> dependent waveforms. As these waveforms are proprietary [2] the rM
>>> team runs closed source software called SWTCON in userspace to control
>>> the panel [3].
>>>
>>> This closed source software expects the fbdev mxsfb driver and it
>>> doesn't work with the DRM mxsfb driver (at least not that I can get it
>>> to).
>>>
>>> The NXP fork of Linux also re-adds the fbdev driver [4], so they also
>>> see some uses for it.
>>>
>>> I was wondering if the community would be open to re-adding the fbdev
>>> mxsfb driver to mainline? It could be re-added with a different
>>> dt-binding so that it is not used by default and only enabled for
>>> boards when required (like for the rM2).
>>>
>>> 1: https://remarkable.com/store/remarkable-2
>>> 2: https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-closely-guarded-secret
>>> 3: https://remarkablewiki.com/tech/rm2_framebuffer
>>> 4: https://source.codeaurora.org/external/imx/linux-imx/log/drivers/video/fbdev/mxsfb.c?h=lf-5.10.35-2.0.0
>>
>> +CC Sam.
>>
>> What sort of special thing does your proprietary userspace do that
>> cannot be added to the DRM driver or the fbdev emulation (if needed) ?
> 
> It's hard to tell. When using the DRM driver I get cryptic errors
> about the frame buffer not being available.

Do you have fbdev emulation enabled ? Does /dev/fbX exist ?

What sort of messages do you get and from where ?

You could run strace on the application to see how it communicates with 
the old driver via the ioctl interface and compare it with the fbdev 
emulation on the new driver, maybe there is some odd ioctl which is not 
emulated.

There is also NXP 5.10.35 fork, so you could try picking the fbdev 
driver from there and add printks/trace_printks/etc. into both that and 
the fbdev emulation code, to see whether how either is called and what 
is failing/missing in the emulation.

> It's difficult to know
> what is going on as I don't have access to any of the source. I
> suspect the userspace code could be updated to use the DRM driver, but
> we would need the reMarkable devs to do that.
> 
> There is some effort to re-implement the proprietary user space swtcon
> (https://github.com/timower/rM2-stuff#swtcon), but it seems to have
> stalled. It wouldn't be impossible to get swtcon to work with the DRM
> driver, but it would require a very large amount of reverse
> engineering, that probably will never happen.
> 
> I wanted to see what the thoughts were on re-adding the fbdev mxsfb
> driver. The commit message just says that because there is a DRM
> driver we no longer need the fbdev one, but here is a case for the
> fbdev driver. I was thinking that continuing to support the fbdev
> mxsfb driver wouldn't be too much of a maintenance burden (but that's
> obviously up to you). The NXP tree also seems to think the fbdev
> driver is worth keeping around.

I don't think the NXP tree is a particularly good example of best 
practice, they don't use the mxsfb in the first place, they wrote their 
own DRM driver for the LCDIF IP, and they also keep the fbdev driver 
around, so yes, they have three drivers for the same IP in different 
state of decay and with different problems, instead of one driver that 
has all the functionality and fixes. Sigh ...

I cannot decide on the fbdev thing, that's I think up to Sam. However, 
my suggestion would be to find out what is missing in the fbdev 
emulation and possibly fill that in, so we will have only one driver to 
support all the functionality.

Re: Revert "video: fbdev: mxsfb: Remove driver"

[Alistair Francis]

On Mon, Aug 16, 2021 at 5:55 PM Marek Vasut <marex@denx.de> wrote:
>
> On 8/16/21 9:34 AM, Alistair Francis wrote:
> > On Sun, Aug 15, 2021 at 10:31 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 8/15/21 2:16 PM, Alistair Francis wrote:
> >>> Hello,
> >>>
> >>> Commit f225f1393f034 "video: fbdev: mxsfb: Remove driver" removed the
> >>> mxsfb fbdev driver.
> >>>
> >>> I am now working on getting mainline Linux running on the reMarkable 2
> >>> eInk reader [1]. Unfortunately the rM2 doesn't use the standard EPD
> >>> controller on the i.MX SoC, but instead uses the LCD controller.
> >>>
> >>> eInk panels are complex to control and require writing temperature
> >>> dependent waveforms. As these waveforms are proprietary [2] the rM
> >>> team runs closed source software called SWTCON in userspace to control
> >>> the panel [3].
> >>>
> >>> This closed source software expects the fbdev mxsfb driver and it
> >>> doesn't work with the DRM mxsfb driver (at least not that I can get it
> >>> to).
> >>>
> >>> The NXP fork of Linux also re-adds the fbdev driver [4], so they also
> >>> see some uses for it.
> >>>
> >>> I was wondering if the community would be open to re-adding the fbdev
> >>> mxsfb driver to mainline? It could be re-added with a different
> >>> dt-binding so that it is not used by default and only enabled for
> >>> boards when required (like for the rM2).
> >>>
> >>> 1: https://remarkable.com/store/remarkable-2
> >>> 2: https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-closely-guarded-secret
> >>> 3: https://remarkablewiki.com/tech/rm2_framebuffer
> >>> 4: https://source.codeaurora.org/external/imx/linux-imx/log/drivers/video/fbdev/mxsfb.c?h=lf-5.10.35-2.0.0
> >>
> >> +CC Sam.
> >>
> >> What sort of special thing does your proprietary userspace do that
> >> cannot be added to the DRM driver or the fbdev emulation (if needed) ?
> >
> > It's hard to tell. When using the DRM driver I get cryptic errors
> > about the frame buffer not being available.
>
> Do you have fbdev emulation enabled ? Does /dev/fbX exist ?

I do and /dev/fb0 exists

>
> What sort of messages do you get and from where ?

This is the error I get:

xochitl[252]: Error writing variable information: Invalid argument...

xochitl is the proprietary userspace code. I don't really have a good
idea of what that error would mean.

I also see this:

Framebuffer has wrong id: "mxcfb"

>
> You could run strace on the application to see how it communicates with
> the old driver via the ioctl interface and compare it with the fbdev
> emulation on the new driver, maybe there is some odd ioctl which is not
> emulated.

I had a quick look at this.

xochitl does a lot more than just controls the display, it interacts
with lots of other hardware and strace produces a lot of logs. I also
don't see the error when manually starting it, only at boot (but it
still doesn't work).

A quick run with

strace -f xochitcl

and I don't even see an access to /dev/fb0, so I'm not sure where the
accesses are coming from.

Alistair

>
> There is also NXP 5.10.35 fork, so you could try picking the fbdev
> driver from there and add printks/trace_printks/etc. into both that and
> the fbdev emulation code, to see whether how either is called and what
> is failing/missing in the emulation.
>
> > It's difficult to know
> > what is going on as I don't have access to any of the source. I
> > suspect the userspace code could be updated to use the DRM driver, but
> > we would need the reMarkable devs to do that.
> >
> > There is some effort to re-implement the proprietary user space swtcon
> > (https://github.com/timower/rM2-stuff#swtcon), but it seems to have
> > stalled. It wouldn't be impossible to get swtcon to work with the DRM
> > driver, but it would require a very large amount of reverse
> > engineering, that probably will never happen.
> >
> > I wanted to see what the thoughts were on re-adding the fbdev mxsfb
> > driver. The commit message just says that because there is a DRM
> > driver we no longer need the fbdev one, but here is a case for the
> > fbdev driver. I was thinking that continuing to support the fbdev
> > mxsfb driver wouldn't be too much of a maintenance burden (but that's
> > obviously up to you). The NXP tree also seems to think the fbdev
> > driver is worth keeping around.
>
> I don't think the NXP tree is a particularly good example of best
> practice, they don't use the mxsfb in the first place, they wrote their
> own DRM driver for the LCDIF IP, and they also keep the fbdev driver
> around, so yes, they have three drivers for the same IP in different
> state of decay and with different problems, instead of one driver that
> has all the functionality and fixes. Sigh ...
>
> I cannot decide on the fbdev thing, that's I think up to Sam. However,
> my suggestion would be to find out what is missing in the fbdev
> emulation and possibly fill that in, so we will have only one driver to
> support all the functionality.

Re: Revert "video: fbdev: mxsfb: Remove driver"

[Marek Vasut]

On 8/17/21 11:08 AM, Alistair Francis wrote:
> On Mon, Aug 16, 2021 at 5:55 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 8/16/21 9:34 AM, Alistair Francis wrote:
>>> On Sun, Aug 15, 2021 at 10:31 PM Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 8/15/21 2:16 PM, Alistair Francis wrote:
>>>>> Hello,
>>>>>
>>>>> Commit f225f1393f034 "video: fbdev: mxsfb: Remove driver" removed the
>>>>> mxsfb fbdev driver.
>>>>>
>>>>> I am now working on getting mainline Linux running on the reMarkable 2
>>>>> eInk reader [1]. Unfortunately the rM2 doesn't use the standard EPD
>>>>> controller on the i.MX SoC, but instead uses the LCD controller.
>>>>>
>>>>> eInk panels are complex to control and require writing temperature
>>>>> dependent waveforms. As these waveforms are proprietary [2] the rM
>>>>> team runs closed source software called SWTCON in userspace to control
>>>>> the panel [3].
>>>>>
>>>>> This closed source software expects the fbdev mxsfb driver and it
>>>>> doesn't work with the DRM mxsfb driver (at least not that I can get it
>>>>> to).
>>>>>
>>>>> The NXP fork of Linux also re-adds the fbdev driver [4], so they also
>>>>> see some uses for it.
>>>>>
>>>>> I was wondering if the community would be open to re-adding the fbdev
>>>>> mxsfb driver to mainline? It could be re-added with a different
>>>>> dt-binding so that it is not used by default and only enabled for
>>>>> boards when required (like for the rM2).
>>>>>
>>>>> 1: https://remarkable.com/store/remarkable-2
>>>>> 2: https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-closely-guarded-secret
>>>>> 3: https://remarkablewiki.com/tech/rm2_framebuffer
>>>>> 4: https://source.codeaurora.org/external/imx/linux-imx/log/drivers/video/fbdev/mxsfb.c?h=lf-5.10.35-2.0.0
>>>>
>>>> +CC Sam.
>>>>
>>>> What sort of special thing does your proprietary userspace do that
>>>> cannot be added to the DRM driver or the fbdev emulation (if needed) ?
>>>
>>> It's hard to tell. When using the DRM driver I get cryptic errors
>>> about the frame buffer not being available.
>>
>> Do you have fbdev emulation enabled ? Does /dev/fbX exist ?
> 
> I do and /dev/fb0 exists
> 
>>
>> What sort of messages do you get and from where ?
> 
> This is the error I get:
> 
> xochitl[252]: Error writing variable information: Invalid argument...

Some ioctl returns -EINVAL maybe ? strace would tell you.

> xochitl is the proprietary userspace code. I don't really have a good
> idea of what that error would mean.
> 
> I also see this:
> 
> Framebuffer has wrong id: "mxcfb"

Are you sure you're not confusing mxcfb (The freescale imx scanout 
engine) with mxsfb (The originally sgtl block, bought by freescale) ?

>> You could run strace on the application to see how it communicates with
>> the old driver via the ioctl interface and compare it with the fbdev
>> emulation on the new driver, maybe there is some odd ioctl which is not
>> emulated.
> 
> I had a quick look at this.
> 
> xochitl does a lot more than just controls the display, it interacts
> with lots of other hardware and strace produces a lot of logs. I also
> don't see the error when manually starting it, only at boot (but it
> still doesn't work).
> 
> A quick run with
> 
> strace -f xochitcl
> 
> and I don't even see an access to /dev/fb0, so I'm not sure where the
> accesses are coming from.

You can try writing the output of strace to file (strace -o) for easier 
analysis. Then grep for either access to /dev/fb0 (or any symlink to it 
which might exist), or search for the mxcfb string, maybe the 
application aborts even before opening the fbdev due to some other problem.

Re: Revert "video: fbdev: mxsfb: Remove driver"

[Alistair Francis]

On Tue, Aug 17, 2021 at 8:03 PM Marek Vasut <marex@denx.de> wrote:
>
> On 8/17/21 11:08 AM, Alistair Francis wrote:
> > On Mon, Aug 16, 2021 at 5:55 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 8/16/21 9:34 AM, Alistair Francis wrote:
> >>> On Sun, Aug 15, 2021 at 10:31 PM Marek Vasut <marex@denx.de> wrote:
> >>>>
> >>>> On 8/15/21 2:16 PM, Alistair Francis wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Commit f225f1393f034 "video: fbdev: mxsfb: Remove driver" removed the
> >>>>> mxsfb fbdev driver.
> >>>>>
> >>>>> I am now working on getting mainline Linux running on the reMarkable 2
> >>>>> eInk reader [1]. Unfortunately the rM2 doesn't use the standard EPD
> >>>>> controller on the i.MX SoC, but instead uses the LCD controller.
> >>>>>
> >>>>> eInk panels are complex to control and require writing temperature
> >>>>> dependent waveforms. As these waveforms are proprietary [2] the rM
> >>>>> team runs closed source software called SWTCON in userspace to control
> >>>>> the panel [3].
> >>>>>
> >>>>> This closed source software expects the fbdev mxsfb driver and it
> >>>>> doesn't work with the DRM mxsfb driver (at least not that I can get it
> >>>>> to).
> >>>>>
> >>>>> The NXP fork of Linux also re-adds the fbdev driver [4], so they also
> >>>>> see some uses for it.
> >>>>>
> >>>>> I was wondering if the community would be open to re-adding the fbdev
> >>>>> mxsfb driver to mainline? It could be re-added with a different
> >>>>> dt-binding so that it is not used by default and only enabled for
> >>>>> boards when required (like for the rM2).
> >>>>>
> >>>>> 1: https://remarkable.com/store/remarkable-2
> >>>>> 2: https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-closely-guarded-secret
> >>>>> 3: https://remarkablewiki.com/tech/rm2_framebuffer
> >>>>> 4: https://source.codeaurora.org/external/imx/linux-imx/log/drivers/video/fbdev/mxsfb.c?h=lf-5.10.35-2.0.0
> >>>>
> >>>> +CC Sam.
> >>>>
> >>>> What sort of special thing does your proprietary userspace do that
> >>>> cannot be added to the DRM driver or the fbdev emulation (if needed) ?
> >>>
> >>> It's hard to tell. When using the DRM driver I get cryptic errors
> >>> about the frame buffer not being available.
> >>
> >> Do you have fbdev emulation enabled ? Does /dev/fbX exist ?
> >
> > I do and /dev/fb0 exists
> >
> >>
> >> What sort of messages do you get and from where ?
> >
> > This is the error I get:
> >
> > xochitl[252]: Error writing variable information: Invalid argument...
>
> Some ioctl returns -EINVAL maybe ? strace would tell you.

Ok, good progress. When xochitl works or doesn't work I see this for
strace accesses:

```
openat(AT_FDCWD, "/dev/fb0", O_RDWR) = 5
```

That's the only access for both the working case or the non-working case.

The actual application provides this log for the not working case
(where it then hangs)

```
/usr/bin/xochitl --system
10:53.013 default                  2021-06-11T11:42:05Z
heads/releases/bertwhistle 264f47ba0 (int main(int, char**)
/usr/src/debug/xochitl/override+gitAUTOINC+264f47ba03-r0/git/src/main.cpp:294)
Registering exit handlers
10:53.018 default                  we're running on an epaper device
(int main(int, char**)
/usr/src/debug/xochitl/override+gitAUTOINC+264f47ba03-r0/git/src/main.cpp:301)
Reading waveforms from
/usr/share/remarkable/320_R349_AF0411_ED103TC2U2_VB3300-KCD_TC.wbf
Error writing variable information: Invalid argument
```

These are the EINVAL strace tells me in the not working case:

prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument)
ioctl(5, FBIOPUT_VSCREENINFO, 0x4ce8e0) = -1 EINVAL (Invalid argument)

I'm guessing it's related to FBIOPUT_VSCREENINFO then, is that
something that could be added to the DRM emulation?

>
> > xochitl is the proprietary userspace code. I don't really have a good
> > idea of what that error would mean.
> >
> > I also see this:
> >
> > Framebuffer has wrong id: "mxcfb"
>
> Are you sure you're not confusing mxcfb (The freescale imx scanout
> engine) with mxsfb (The originally sgtl block, bought by freescale) ?

This is the full commit that gets everything working for me:
https://github.com/alistair23/linux/commit/ee0e684e3d776c6de98b6491d1a87d8305c44734

It includes mxcfb, but I think that is just to allow the mxsfb to compile.

>
> >> You could run strace on the application to see how it communicates with
> >> the old driver via the ioctl interface and compare it with the fbdev
> >> emulation on the new driver, maybe there is some odd ioctl which is not
> >> emulated.
> >
> > I had a quick look at this.
> >
> > xochitl does a lot more than just controls the display, it interacts
> > with lots of other hardware and strace produces a lot of logs. I also
> > don't see the error when manually starting it, only at boot (but it
> > still doesn't work).
> >
> > A quick run with
> >
> > strace -f xochitcl
> >
> > and I don't even see an access to /dev/fb0, so I'm not sure where the
> > accesses are coming from.
>
> You can try writing the output of strace to file (strace -o) for easier
> analysis. Then grep for either access to /dev/fb0 (or any symlink to it
> which might exist), or search for the mxcfb string, maybe the
> application aborts even before opening the fbdev due to some other problem.

Thanks, I figured out there was a script that I was running instead. I
can now see the /dev/fb0 access.


Alistair

Re: Revert "video: fbdev: mxsfb: Remove driver"

[Alistair Francis]

On Thu, Aug 19, 2021 at 4:31 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Alistair,
>
> > prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > ioctl(5, FBIOPUT_VSCREENINFO, 0x4ce8e0) = -1 EINVAL (Invalid argument)
> >
> > I'm guessing it's related to FBIOPUT_VSCREENINFO then, is that
> > something that could be added to the DRM emulation?
>
> Just to try to verify this could you try to return early
> in the switch where we have FBIOPUT_VSCREENINFO?
>
> In fbmem.c in do_fb_ioctl() just add a printk("something\n") and
> return 0 in the FBIOPUT_VSCREENINFO case.

Yep, this diff changes the working screen with the fbdev driver to not working:

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 1c855145711b..0f781914eca0 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1099,18 +1099,8 @@ static long do_fb_ioctl(struct fb_info *info,
unsigned int cmd,
                ret = copy_to_user(argp, &var, sizeof(var)) ? -EFAULT : 0;
                break;
        case FBIOPUT_VSCREENINFO:
-               if (copy_from_user(&var, argp, sizeof(var)))
-                       return -EFAULT;
-               console_lock();
-               lock_fb_info(info);
-               ret = fb_set_var(info, &var);
-               if (!ret)
-                       fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
-               unlock_fb_info(info);
-               console_unlock();
-               if (!ret && copy_to_user(argp, &var, sizeof(var)))
-                       ret = -EFAULT;
-               break;
+               printk("FBIOPUT_VSCREENINFO Returning early");
+               return -EINVAL;
        case FBIOGET_FSCREENINFO:
                lock_fb_info(info);
                memcpy(&fix, &info->fix, sizeof(fix));

So FBIOPUT_VSCREENINFO is the issue (or at least one of them).

Alistair

>
> The printk is just so something pops up in the logging.
>
> If this makes you going then we need to look at how to add this to the
> emulation or some other way to deal with this.
>
>         Sam

Re: Revert "video: fbdev: mxsfb: Remove driver"

[Alistair Francis]

On Thu, Aug 19, 2021 at 4:38 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Alistair,
>
> >
> > These are the EINVAL strace tells me in the not working case:
> >
> > prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > ioctl(5, FBIOPUT_VSCREENINFO, 0x4ce8e0) = -1 EINVAL (Invalid argument)
> >
> > I'm guessing it's related to FBIOPUT_VSCREENINFO then, is that
> > something that could be added to the DRM emulation?
>
> If it turns out FBIOPUT_VSCREENINFO is the culprint it would also be
> good to know why we see EINVAL.
> One way is to sprinkle a number of printk's in fb_set_var(),
> then you can see how far you get before it fails.

Thanks for the help.

I see this line:

ret = info->fbops->fb_check_var(var, info);

in fb_set_var()

returning early.

Alistair

>
> This could hopefully give a clue why this fails with fbdev emulation.
>
>         Sam

Re: Revert "video: fbdev: mxsfb: Remove driver"

[Alistair Francis]

On Fri, Aug 20, 2021 at 1:43 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Alistair,
>
> On Thu, Aug 19, 2021 at 07:10:00PM +1000, Alistair Francis wrote:
> > On Thu, Aug 19, 2021 at 4:38 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> > >
> > > Hi Alistair,
> > >
> > > >
> > > > These are the EINVAL strace tells me in the not working case:
> > > >
> > > > prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > ioctl(5, FBIOPUT_VSCREENINFO, 0x4ce8e0) = -1 EINVAL (Invalid argument)
> > > >
> > > > I'm guessing it's related to FBIOPUT_VSCREENINFO then, is that
> > > > something that could be added to the DRM emulation?
> > >
> > > If it turns out FBIOPUT_VSCREENINFO is the culprint it would also be
> > > good to know why we see EINVAL.
> > > One way is to sprinkle a number of printk's in fb_set_var(),
> > > then you can see how far you get before it fails.
> >
> > Thanks for the help.
> >
> > I see this line:
> >
> > ret = info->fbops->fb_check_var(var, info);
> >
> > in fb_set_var()
> >
> > returning early.
>
> Super, then next step is to annotate drm_fb_helper_check_var()
> to see where it fails.
> Try this and let us know the result.

Thanks!

After adding some prints, I realised there are already some in there
that are disabled by default. After enabling them I see this:

"fbdev emulation doesn't support changing the pixel clock, value of
pixclock is ignored"

and

"fb requested width/height/bpp can't fit in current fb request
260x1408-32 (virtual 260x23936) > 334x1405-32"

which returns EINVAL.

This is where I'm confused though. The values 334 and 1405 are taken
from the vendor and in the working fbdev driver they are using the
same values.

I tried to add a similar print to mxsfb_check_var() for the working
version, to check what the values are, but there doesn't seem to be
any equivalent of fb->width and friends.

Any ideas?

Alistair

>
>         Sam

Re: Revert "video: fbdev: mxsfb: Remove driver"

[Alistair Francis]

On Fri, Aug 20, 2021 at 8:36 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Fri, Aug 20, 2021 at 1:43 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > Hi Alistair,
> >
> > On Thu, Aug 19, 2021 at 07:10:00PM +1000, Alistair Francis wrote:
> > > On Thu, Aug 19, 2021 at 4:38 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> > > >
> > > > Hi Alistair,
> > > >
> > > > >
> > > > > These are the EINVAL strace tells me in the not working case:
> > > > >
> > > > > prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > > prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > > prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > > prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > > ioctl(5, FBIOPUT_VSCREENINFO, 0x4ce8e0) = -1 EINVAL (Invalid argument)
> > > > >
> > > > > I'm guessing it's related to FBIOPUT_VSCREENINFO then, is that
> > > > > something that could be added to the DRM emulation?
> > > >
> > > > If it turns out FBIOPUT_VSCREENINFO is the culprint it would also be
> > > > good to know why we see EINVAL.
> > > > One way is to sprinkle a number of printk's in fb_set_var(),
> > > > then you can see how far you get before it fails.
> > >
> > > Thanks for the help.
> > >
> > > I see this line:
> > >
> > > ret = info->fbops->fb_check_var(var, info);
> > >
> > > in fb_set_var()
> > >
> > > returning early.
> >
> > Super, then next step is to annotate drm_fb_helper_check_var()
> > to see where it fails.
> > Try this and let us know the result.
>
> Thanks!
>
> After adding some prints, I realised there are already some in there
> that are disabled by default. After enabling them I see this:
>
> "fbdev emulation doesn't support changing the pixel clock, value of
> pixclock is ignored"
>
> and
>
> "fb requested width/height/bpp can't fit in current fb request
> 260x1408-32 (virtual 260x23936) > 334x1405-32"
>
> which returns EINVAL.
>
> This is where I'm confused though. The values 334 and 1405 are taken
> from the vendor and in the working fbdev driver they are using the
> same values.
>
> I tried to add a similar print to mxsfb_check_var() for the working
> version, to check what the values are, but there doesn't seem to be
> any equivalent of fb->width and friends.

I dug into this some more.

In the working mxsfb and non-working fbdev emulation the userspace
software sets:

xres: 260
yres: 1408
xres_virtual: 260
yres_virtual: 23936

That passes the old mxsfb_check_var() and works.

While that fails the new fbdev emulation check. Even increasing the
width and height from 334x14085 to 260x23936 doesn't help as I get a
range of other errors and no display. Just removing the check also
doesn't work and results in kernel panics.

It seems there is some difference in handling the resolutions between
the mxsfb driver and the fbdev emulation on the new DRM driver. I'm
just not sure what the difference is.

Alistair

Re: Revert "video: fbdev: mxsfb: Remove driver"

[Alistair Francis]

On Thu, Oct 14, 2021 at 7:56 PM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Fri, Aug 20, 2021 at 8:36 AM Alistair Francis <alistair23@gmail.com> wrote:
> >
> > On Fri, Aug 20, 2021 at 1:43 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> > >
> > > Hi Alistair,
> > >
> > > On Thu, Aug 19, 2021 at 07:10:00PM +1000, Alistair Francis wrote:
> > > > On Thu, Aug 19, 2021 at 4:38 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> > > > >
> > > > > Hi Alistair,
> > > > >
> > > > > >
> > > > > > These are the EINVAL strace tells me in the not working case:
> > > > > >
> > > > > > prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > > > prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > > > prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > > > prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument)
> > > > > > ioctl(5, FBIOPUT_VSCREENINFO, 0x4ce8e0) = -1 EINVAL (Invalid argument)
> > > > > >
> > > > > > I'm guessing it's related to FBIOPUT_VSCREENINFO then, is that
> > > > > > something that could be added to the DRM emulation?
> > > > >
> > > > > If it turns out FBIOPUT_VSCREENINFO is the culprint it would also be
> > > > > good to know why we see EINVAL.
> > > > > One way is to sprinkle a number of printk's in fb_set_var(),
> > > > > then you can see how far you get before it fails.
> > > >
> > > > Thanks for the help.
> > > >
> > > > I see this line:
> > > >
> > > > ret = info->fbops->fb_check_var(var, info);
> > > >
> > > > in fb_set_var()
> > > >
> > > > returning early.
> > >
> > > Super, then next step is to annotate drm_fb_helper_check_var()
> > > to see where it fails.
> > > Try this and let us know the result.
> >
> > Thanks!
> >
> > After adding some prints, I realised there are already some in there
> > that are disabled by default. After enabling them I see this:
> >
> > "fbdev emulation doesn't support changing the pixel clock, value of
> > pixclock is ignored"
> >
> > and
> >
> > "fb requested width/height/bpp can't fit in current fb request
> > 260x1408-32 (virtual 260x23936) > 334x1405-32"
> >
> > which returns EINVAL.
> >
> > This is where I'm confused though. The values 334 and 1405 are taken
> > from the vendor and in the working fbdev driver they are using the
> > same values.
> >
> > I tried to add a similar print to mxsfb_check_var() for the working
> > version, to check what the values are, but there doesn't seem to be
> > any equivalent of fb->width and friends.
>
> I dug into this some more.
>
> In the working mxsfb and non-working fbdev emulation the userspace
> software sets:
>
> xres: 260
> yres: 1408
> xres_virtual: 260
> yres_virtual: 23936
>
> That passes the old mxsfb_check_var() and works.
>
> While that fails the new fbdev emulation check. Even increasing the
> width and height from 334x14085 to 260x23936 doesn't help as I get a
> range of other errors and no display. Just removing the check also
> doesn't work and results in kernel panics.
>
> It seems there is some difference in handling the resolutions between
> the mxsfb driver and the fbdev emulation on the new DRM driver. I'm
> just not sure what the difference is.

There is some progress to reverse engineer the userspace code, this is
the call that is failing:
https://github.com/matteodelabre/waved/blob/main/src/display.cpp#L628
. The values being passed in are set above:
https://github.com/matteodelabre/waved/blob/main/src/display.cpp#L118
. The code is setting a virtual y_res based on 17 frames.

The comment in drm_fb_helper.c::drm_fb_helper_check_var(), "Changes
struct fb_var_screeninfo are currently not pushed back to KMS, hence
fail if different settings are requested." probably sums up the issue.
It seems like the FB emulation doesn't support the number of frames.

I don't have a good idea of if this could be done with the emulation
though, or if re-adding the mxsfb driver is the better option.

>
> Alistair