LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Alistair Francis <alistair23@gmail.com>
To: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <kernel@pengutronix.de>,
	dl-linux-imx <linux-imx@nxp.com>,
	b.zolnierkie@samsung.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alistair Francis <alistair@alistair23.me>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: Revert "video: fbdev: mxsfb: Remove driver"
Date: Tue, 17 Aug 2021 22:16:14 +1000	[thread overview]
Message-ID: <CAKmqyKN8devNyDvVL5B_dDASU3se1dSui0bsnf6gQ+CkZ_TaKg@mail.gmail.com> (raw)
In-Reply-To: <ab2b7f4f-3e36-461c-6a6c-02ee7ed6cb99@denx.de>

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

  reply	other threads:[~2021-08-17 12:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-15 12:16 Revert "video: fbdev: mxsfb: Remove driver" Alistair Francis
2021-08-15 12:31 ` Marek Vasut
2021-08-16  7:34   ` Alistair Francis
2021-08-16  7:55     ` Marek Vasut
2021-08-17  9:08       ` Alistair Francis
2021-08-17 10:03         ` Marek Vasut
2021-08-17 12:16           ` Alistair Francis [this message]
     [not found]             ` <YR1R7/nIUIN3LA7t@ravnborg.org>
2021-08-19  8:16               ` Alistair Francis
     [not found]             ` <YR1Th65KKRS4D/6+@ravnborg.org>
2021-08-19  9:10               ` Alistair Francis
     [not found]                 ` <YR58MvAYYEjBQ7l5@ravnborg.org>
2021-08-19 22:36                   ` Alistair Francis
2021-10-14  9:56                     ` Alistair Francis
2021-10-21 10:42                       ` Alistair Francis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKmqyKN8devNyDvVL5B_dDASU3se1dSui0bsnf6gQ+CkZ_TaKg@mail.gmail.com \
    --to=alistair23@gmail.com \
    --cc=alistair@alistair23.me \
    --cc=b.zolnierkie@samsung.com \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=sam@ravnborg.org \
    --cc=shawnguo@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).