From: Daniel Vetter <email@example.com>
To: "Jan Sebastian Götte" <firstname.lastname@example.org>
Cc: dri-devel <email@example.com>,
"Noralf Trønnes" <firstname.lastname@example.org>,
"David Airlie" <email@example.com>,
"Linux Kernel Mailing List" <firstname.lastname@example.org>
Subject: Re: [RFC PATCH 0/6] tiny: Add driver for gooddisplay epaper panels
Date: Tue, 30 Jul 2019 16:26:47 +0200 [thread overview]
Message-ID: <CAKMK7uFBSHbEU3Nk3=dNnyt1pO_B83VCYTvbcfUiwomzXbR3Ew@mail.gmail.com> (raw)
On Tue, Jul 30, 2019 at 3:46 PM Jan Sebastian Götte <email@example.com> wrote:
> I've been working on a tinydrm-based driver for black/white/red, b/w/yellow and b/w epaper displays made by good display[sic!]. These panels are fairly popular since waveshare sells raspberry pi and arduino-compatible breakout boards with them.
> The current state of the art in open source software as well as the vendors examples on how to drive these seems to be "pour some fairy dust into /dev/mem". This cannot stand, so here is a (tested, working) tinydrm driver. I've got working color output on two black/white/red panels (2.7" and 4.2") from python, and I have a kernel console showing up[3,4] and I can print colorful cows using cowsay and some ANSI escape sequences.
> In this rfc patch I've added a couple ioctls to allow userspace to control refresh behavior. IMO this is necessary for a fully working driver: These displays support partial refresh, and you can use that to do proper animations. But for this to work, you need to fine-tune the display's driving waveforms depending on the content displayed.
> I have a couple of questions regarding this driver, thus the RFC:
> (1) By default, when loading the module a vt console binds to the fb. I think this is useful, but the cursor blink of the vt leads to an eternal refresh loop. Refresh on these displays is *extremely* slow (1 frame per 15s), so ideally I'd want the cursor to not blink. Is there some nice way to tell the vt/console driver to do this by default?
Hm maybe there is something, but this is the first epaper driver, so I
guess even if it's exists already in fbcon, you'd need to wire through
a flag from drm to drm fbdev emulation to fbdev core to fbcon that
cursors should better not blink.
> (2) Is ioctl the correct interface for the driving waveform/refresh stuff?
For kms, no. In general kms is supposed to be standardized and
generic, and uses properties. I think Emil already comment a bit with
pointers what you should look into instead for each part. For partial
updates we have the damage rectangle stuff now, but no idea whether
that's good enough for what you need.
> (3) I read that any drm driver has to be committed along with a libdrm implementation. I think the most likely interface for anyone to interact with this driver would be the fb dev. Do I have to make some userspace implementation as well anyway? If so, where would that go: libdrm or some sort of new libepaper?
Even more strict: we require full open source userspace, per
But since kms is standardized you should be able to create a driver
for it with no new changes in userspace at all.
> (4) The driver accepts both XRGB8888 and RGB565 (for compatibility with small LCDs). The driver's current approach to calculate a b/w/r "ternary" image from this data is to just take the MSBs of each color component, then make anything red (R>127, G,B<=127) red, anything black (R,G,B each <=127) black and anything else white. This is since the display's default state is white, and a pixel can turn either red or black from that. Note that it's the actual pixel changing color, i.e. there is no black and red sub-pixels. If you try to drive black and red at the same time, the chip just selects red for that pixel. What are your thoughts on this interface? I was thinking about using some indexed color mode, but that would limit possible future grayscale support.
Hm generally we're trying not to fake stuff in the kernel driver in
drm. XRGB8888 is an exception because too much stuff blindly assumes
it exists. I think what we want here is an epaper drm_fourcc.h code,
at least long-term. But since that's new userspace api it also means
we need some open source userspace to drive it. I think best approach
would be to get the basic driver with XRGB8888 emulation merged first,
and then figure out how to best add the specific epaper formats to
fully expose the underlying capabilities.
> The following patches all apply on v5.2. This is my first linux driver, so please be gentle but please do point out all my mistakes :) I'm aware the dt binding doc is still lacking.
So the great and also somewhat tricky bit is that support code for
tiny drivers is evolving really quick, so would be good if you can
rebase onto drm-misc-next from
https://cgit.freedesktop.org/drm/drm-misc/ There's still tons
in-flight, but that should at least help. One notable series that
didn't land yet renames tindydrm to drm/tiny/, so maybe wait for that
to land (it hopefully should land soon I think).
> Best regards,
> Jan Sebastian Götte
>  https://www.good-display.com/
>  https://www.waveshare.com/product/modules/oleds-lcds/e-paper.htm
>  https://blog.jaseg.net/images/epaper3.jpg
>  https://blog.jaseg.net/images/epaper1.jpg
>  https://blog.jaseg.net/images/epaper2.jpg
>  https://blog.jaseg.net/images/epaper4.jpg
>  https://www.youtube.com/watch?v=MsbiO8EAsGw
>  https://github.com/zkarcher/FancyEPD
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2019-07-30 14:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-30 13:46 [RFC PATCH 0/6] tiny: Add driver for gooddisplay epaper panels Jan Sebastian Götte
2019-07-30 13:47 ` [PATCH 1/6] drm: tiny: gdepaper: add TINYDRM_GDEPAPER config option Jan Sebastian Götte
2019-07-30 13:48 ` [PATCH 2/6] dt-bindings: add gooddisplay vendor prefix Jan Sebastian Götte
2019-07-30 13:48 ` [PATCH 3/6] dt-bindings: add good display epaper header Jan Sebastian Götte
2019-07-30 13:48 ` [PATCH 4/6] dt-bindings: add gdepaper documentation Jan Sebastian Götte
2019-07-30 13:48 ` [PATCH 5/6] drm: uapi: add gdepaper uapi header Jan Sebastian Götte
2019-07-30 14:08 ` Emil Velikov
2019-07-30 16:21 ` Jan Sebastian Götte
2019-07-30 16:49 ` Emil Velikov
2019-07-31 2:01 ` Jan Sebastian Götte
2019-07-31 6:47 ` Daniel Vetter
2019-07-30 13:48 ` [PATCH 6/6] drm: tiny: gdepaper: add driver for 2/3 color epaper displays Jan Sebastian Götte
2019-08-06 16:06 ` Noralf Trønnes
2019-08-10 5:17 ` Jan Sebastian Götte
2019-07-30 14:26 ` Daniel Vetter [this message]
2019-07-30 16:24 ` [RFC PATCH 0/6] tiny: Add driver for gooddisplay epaper panels Jan Sebastian Götte
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).