[RFC 0/3] drm: Add DRM text mode

[Ken Phillis Jr]

I like the idea of the whole DRM Text mode driver set, and would you be
open to changing the license to  (or possibly adding a dual license option)
involving the MIT[1], BSD 2-clause[2], or BSD 3-clause[3]. This would
simplify the porting of this driver to other platforms ( for example
FreeBSD, DragonFlyBSD, and others ).

[1] https://opensource.org/licenses/MIT
[2] https://opensource.org/licenses/BSD-2-Clause
[3] https://opensource.org/licenses/BSD-3-Clause
-- next part --
An HTML attachment was scrubbed...
URL: 

[RFC 0/3] drm: Add DRM text mode

[Noralf Trønnes]

Den 02.08.2016 15:05, skrev Daniel Vetter:
> On Sat, Jul 30, 2016 at 5:48 PM, Noralf Trønnes  
> wrote:
>> Den 29.07.2016 10:23, skrev Daniel Vetter:
>>> Actually adding David.
>>> -Daniel
>>>
>>> On Fri, Jul 29, 2016 at 10:20:51AM +0200, Daniel Vetter wrote:
 On Thu, Jul 28, 2016 at 04:15:04PM +0200, Noralf Trønnes wrote:



 Aside: Where's the pull request for your driver? ;-)
>>
>> I have been working on tinydrm for 6 months straight now and it wasn't fun
>> anymore. So I figured this was a good time to take a break from it and do
>> something else for a while :-)
> :( Still looking forward to it, I think with all the nice prep work
> you've done it would be a shame if the reason for it all wouldn't make
> it in.

I've spent too much time on tinydrm to drop it now, I just need a break.

Noralf.

[RFC 0/3] drm: Add DRM text mode

[Daniel Vetter]

On Tue, Aug 2, 2016 at 3:41 PM, David Herrmann  wrote:
> Hey
>
> On Thu, Jul 28, 2016 at 4:15 PM, Noralf Trønnes  
> wrote:
>> This patchset explores the idea of adding a DRM text mode
>> (like VGA text mode) to get an alternative to fbcon/fbdev.
>>
>> David Hermann has done alot of work on a fbcon replacement:
>> - drm: add kernel-log renderer (Mar 2014)[1]
>> - kmscon:
>>   development started Nov 2011
>>   added to systemd Oct 2014
>>   removed from systemd Jul 2015[2]
>>
>> Since this work seems to have stalled, I propose an alternative solution
>> to this problem that will also give VT console support while we're waiting
>> for a userspace console.
>>
>> The idea is that the driver provides a modeset like with the fbdev emulation
>> code, and from this a text buffer representation is made. The console code
>> can now write to this text buffer and ask for the text buffer to be
>> flushed/rendered to the pixel buffer.
>>
>> In this hack/implementation of the idea, I have just hijacked a CMA backed
>> fbdev framebuffer to keep it simple.
>> I have reused the default buffer format that VT uses.
>> Getting panic handling to actually work, seems to be a challenge as Daniel
>> describes on the DRMJanitors page[3].
>>
>> Is this idea of a DRM text mode worth developing further?
>
> Sorry, haven't done much on this stuff lately. I still appreciate
> being put on CC, thanks for that!
> I did change my mind several times when working on the VT-replacement
> layer and everything involved. In the end, my plan was this:
>
>  * Make VTs obsolete. Make sure a system can run with CONFIG_VT=n.
> systemd-logind provides an alternative access-control, but I would not
> mind dropping it as well and just go with a setup that only has a
> single gfx/input user per seat. No VTs, no multiplexing, etc. (which
> is what Ubuntu is going for with the system compositor).
>
>  * Make fbdev obsolete. Provide SimpleDRM as a slow-path for any
> graphics device that no real driver exists for. SimpleDRM always runs
> a _shadow_ FB, so no direct access to gfx-resources from user-space.
> If you need that, use something else.
>
>  * Support turnover from SimpleDRM to other drivers. This is as simple
> as destroying the related platform-device before loading a gfx-driver.
> Patches exist, but requires i915 to move aperture-management out of
> the ->load callback (i.e., out of drm_global_mutex). The best solution
> would be to drop ->load entirely. It is not needed, anyway.

Good news: We've just fixed that. And many drivers lost their ->load
callback too (But not yet amdgpu/radeon/nouveau unfortunately).
-Daniel

>  * Write an in-kernel terminal layer that can be loaded as dynamic
> module and is a pure API _consumer_. Nothing can depend on it, hence,
> it is completely passive and can be loaded on-demand (unlike VTs,
> which lots of stuff is hooked into). This terminal/console serves as
> debugging console for developers and can be blended over any current
> screen content. It simply grabs all input and shadows DRM-Master. It
> can be toggled via SYSRQ. User-space is unaware of its existence.
>
> Code for all these parts exists (I even wrote the console replacement
> using the DRM atomic APIs). However, I got distracted with kdbus+bus1,
> so haven't pushed on it lately.
>
> I can see that the drmcon backend you propose is a nice-to-have, but I
> don't think it is the ultimate solution. It is a step forward, though,
> so maybe we should just take it and avoid thinking of the ultimate
> dream-solution... I don't know.
>
> If there is interest in pushing SimpleDRM and/or related parts, ping
> me on IRC (@dvdhrm or via email in private). I'd gladly discuss this
> and try to find some time to revive the patches.
>
> Thanks
> David



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFC 0/3] drm: Add DRM text mode

[David Herrmann]

Hey

On Thu, Jul 28, 2016 at 4:15 PM, Noralf Trønnes  wrote:
> This patchset explores the idea of adding a DRM text mode
> (like VGA text mode) to get an alternative to fbcon/fbdev.
>
> David Hermann has done alot of work on a fbcon replacement:
> - drm: add kernel-log renderer (Mar 2014)[1]
> - kmscon:
>   development started Nov 2011
>   added to systemd Oct 2014
>   removed from systemd Jul 2015[2]
>
> Since this work seems to have stalled, I propose an alternative solution
> to this problem that will also give VT console support while we're waiting
> for a userspace console.
>
> The idea is that the driver provides a modeset like with the fbdev emulation
> code, and from this a text buffer representation is made. The console code
> can now write to this text buffer and ask for the text buffer to be
> flushed/rendered to the pixel buffer.
>
> In this hack/implementation of the idea, I have just hijacked a CMA backed
> fbdev framebuffer to keep it simple.
> I have reused the default buffer format that VT uses.
> Getting panic handling to actually work, seems to be a challenge as Daniel
> describes on the DRMJanitors page[3].
>
> Is this idea of a DRM text mode worth developing further?

Sorry, haven't done much on this stuff lately. I still appreciate
being put on CC, thanks for that!
I did change my mind several times when working on the VT-replacement
layer and everything involved. In the end, my plan was this:

 * Make VTs obsolete. Make sure a system can run with CONFIG_VT=n.
systemd-logind provides an alternative access-control, but I would not
mind dropping it as well and just go with a setup that only has a
single gfx/input user per seat. No VTs, no multiplexing, etc. (which
is what Ubuntu is going for with the system compositor).

 * Make fbdev obsolete. Provide SimpleDRM as a slow-path for any
graphics device that no real driver exists for. SimpleDRM always runs
a _shadow_ FB, so no direct access to gfx-resources from user-space.
If you need that, use something else.

 * Support turnover from SimpleDRM to other drivers. This is as simple
as destroying the related platform-device before loading a gfx-driver.
Patches exist, but requires i915 to move aperture-management out of
the ->load callback (i.e., out of drm_global_mutex). The best solution
would be to drop ->load entirely. It is not needed, anyway.

 * Write an in-kernel terminal layer that can be loaded as dynamic
module and is a pure API _consumer_. Nothing can depend on it, hence,
it is completely passive and can be loaded on-demand (unlike VTs,
which lots of stuff is hooked into). This terminal/console serves as
debugging console for developers and can be blended over any current
screen content. It simply grabs all input and shadows DRM-Master. It
can be toggled via SYSRQ. User-space is unaware of its existence.

Code for all these parts exists (I even wrote the console replacement
using the DRM atomic APIs). However, I got distracted with kdbus+bus1,
so haven't pushed on it lately.

I can see that the drmcon backend you propose is a nice-to-have, but I
don't think it is the ultimate solution. It is a step forward, though,
so maybe we should just take it and avoid thinking of the ultimate
dream-solution... I don't know.

If there is interest in pushing SimpleDRM and/or related parts, ping
me on IRC (@dvdhrm or via email in private). I'd gladly discuss this
and try to find some time to revive the patches.

Thanks
David

[RFC 0/3] drm: Add DRM text mode

[Daniel Vetter]

On Sat, Jul 30, 2016 at 5:48 PM, Noralf Trønnes  wrote:
> Den 29.07.2016 10:23, skrev Daniel Vetter:
>>
>> Actually adding David.
>> -Daniel
>>
>> On Fri, Jul 29, 2016 at 10:20:51AM +0200, Daniel Vetter wrote:
>>>
>>> On Thu, Jul 28, 2016 at 04:15:04PM +0200, Noralf Trønnes wrote:

 This patchset explores the idea of adding a DRM text mode
 (like VGA text mode) to get an alternative to fbcon/fbdev.

 David Hermann has done alot of work on a fbcon replacement:
 - drm: add kernel-log renderer (Mar 2014)[1]
 - kmscon:
development started Nov 2011
added to systemd Oct 2014
removed from systemd Jul 2015[2]

 Since this work seems to have stalled, I propose an alternative solution
 to this problem that will also give VT console support while we're
 waiting
 for a userspace console.

 The idea is that the driver provides a modeset like with the fbdev
 emulation
 code, and from this a text buffer representation is made. The console
 code
 can now write to this text buffer and ask for the text buffer to be
 flushed/rendered to the pixel buffer.

 In this hack/implementation of the idea, I have just hijacked a CMA
 backed
 fbdev framebuffer to keep it simple.
 I have reused the default buffer format that VT uses.
 Getting panic handling to actually work, seems to be a challenge as
 Daniel
 describes on the DRMJanitors page[3].

 Is this idea of a DRM text mode worth developing further?
>>>
>>> I guess some simpler drm console with vt support which would allow us to
>>> get rid of fbdev could make sense. And there's definitely going to be a
>>> lot of overlap with a full userspace solution using something like
>>> kmscon.
>>>
>>> But we can't just add a new drm text console, there's a pile of prep work
>>> needed that David started for either approach:
>>> - Nuking fbdev means no more fbdev drivers for firmware consoles (uboot,
>>>uefi, vga, ...). The simpledrm driver would cover this, would be great
>>>to get that landed (especially now that we have the simple pipe
>>>helpers!).
>
>
> I have rebased simpledrm on drm_simple_display_pipe and have it working on
> a Raspberry Pi. modetest gives me a wrong picture, but that is probably
> because of some wrong format conversion since fbdev using the native
> rgb565 format works fine.
>
> I could finish this up and send a patch unless David is working on
> something?
>
> I have used this version of simpledrm: [PATCH 09/11] drm: add SimpleDRM
> driver
> https://lists.freedesktop.org/archives/dri-devel/2014-January/052594.html

David seems busy with kdbus/bus1 still right now (I chatted with him
on irc), so just go ahead. But please cc him so he can take a quick
look and ack your version.

>>> - One nice benefit of fbdev is that it automatically gets rid of these
>>>firmware-based display drivers when the real driver loads. Some
>>> drivers
>>>do this properly even when fbdev isn't enabled (see
>>> i915_kick_out_vgacon
>>>and i915_kick_out_firmware_fb), but pretty much all others fail in
>>> some
>>>way or the other. David also had some code (iirc as part of simpledrm)
>>>to solve this issue.
>>>
>>> - I think we need more than rbg565 render support, iirc David also had
>>>some work in that area.
>>>
>>> - None of these approaches has a good answer yet to the configuration
>>>question. For a full VT I think we definitely should share the setup
>>>logic with the fbdev emulation code to make it useful, but as describe
>>>in the DRMJanitors page handlings panics is an entierly different
>>>problem.
>>>
>>> Definitely coordinate with David Herrmann here too, since if we do
>>> something in this area it should be widely supported.
>>>
>>> Aside: Where's the pull request for your driver? ;-)
>
>
> I have been working on tinydrm for 6 months straight now and it wasn't fun
> anymore. So I figured this was a good time to take a break from it and do
> something else for a while :-)

:( Still looking forward to it, I think with all the nice prep work
you've done it would be a shame if the reason for it all wouldn't make
it in.
-Daniel


>
>
> Noralf.
>
>
>>> Cheers, Daniel
>>>

 Noralf.

 [1] https://lwn.net/Articles/589858/
 [2] https://github.com/systemd/systemd/pull/747
 [3] https://www.x.org/wiki/DRMJanitors/#makepanichandlingwork


 Noralf Trønnes (3):
drm: Add support for text framebuffer
drm/text: Add panic and boot console support
drm/text: Add VT console support

   drivers/gpu/drm/Makefile|   1 +
   drivers/gpu/drm/drm-text/Makefile   |   5 +
   drivers/gpu/drm/drm-text/drm-text-buffer.c  | 340
 
   drivers/gpu/drm/drm-text/drm-text-console.c | 205 +
   drivers/gpu/drm/drm-text/drm-text-debugfs.c | 295
 

[RFC 0/3] drm: Add DRM text mode

[Daniel Vetter]

On Mon, Aug 1, 2016 at 12:50 PM, Noralf Trønnes  wrote:
>
> Den 30.07.2016 17:48, skrev Noralf Trønnes:
>>
>>
>> Den 29.07.2016 10:23, skrev Daniel Vetter:
>>>
>>> Actually adding David.
>>> -Daniel
>>>
>>> On Fri, Jul 29, 2016 at 10:20:51AM +0200, Daniel Vetter wrote:

 On Thu, Jul 28, 2016 at 04:15:04PM +0200, Noralf Trønnes wrote:
>
> This patchset explores the idea of adding a DRM text mode
> (like VGA text mode) to get an alternative to fbcon/fbdev.
>
> David Hermann has done alot of work on a fbcon replacement:
> - drm: add kernel-log renderer (Mar 2014)[1]
> - kmscon:
>development started Nov 2011
>added to systemd Oct 2014
>removed from systemd Jul 2015[2]
>
> Since this work seems to have stalled, I propose an alternative
> solution
> to this problem that will also give VT console support while we're
> waiting
> for a userspace console.
>
> The idea is that the driver provides a modeset like with the fbdev
> emulation
> code, and from this a text buffer representation is made. The console
> code
> can now write to this text buffer and ask for the text buffer to be
> flushed/rendered to the pixel buffer.
>
> In this hack/implementation of the idea, I have just hijacked a CMA
> backed
> fbdev framebuffer to keep it simple.
> I have reused the default buffer format that VT uses.
> Getting panic handling to actually work, seems to be a challenge as
> Daniel
> describes on the DRMJanitors page[3].
>
> Is this idea of a DRM text mode worth developing further?

 I guess some simpler drm console with vt support which would allow us to
 get rid of fbdev could make sense. And there's definitely going to be a
 lot of overlap with a full userspace solution using something like
 kmscon.

 But we can't just add a new drm text console, there's a pile of prep
 work
 needed that David started for either approach:
 - Nuking fbdev means no more fbdev drivers for firmware consoles (uboot,
uefi, vga, ...). The simpledrm driver would cover this, would be
 great
to get that landed (especially now that we have the simple pipe
helpers!).
>>
>>
>> I have rebased simpledrm on drm_simple_display_pipe and have it working on
>> a Raspberry Pi. modetest gives me a wrong picture, but that is probably
>> because of some wrong format conversion since fbdev using the native
>> rgb565 format works fine.
>>
>> I could finish this up and send a patch unless David is working on
>> something?
>>
>> I have used this version of simpledrm: [PATCH 09/11] drm: add SimpleDRM
>> driver
>> https://lists.freedesktop.org/archives/dri-devel/2014-January/052594.html
>>
>
> I have solved the format conversion problem.
>
> Is there any reason why simpledrm can't use drm_gem_cma_helper?
> This is how it allocates memory:

I'm not sure on the details, but iirc simple_drm must reuse the
framebuffer provided by the firmware. Hence it can't just use any
random pile of memory allocated through other means. But David
probably knows this better.

> int sdrm_gem_get_pages(struct sdrm_gem_object *obj)
> {
> [...]
> num = obj->base.size >> PAGE_SHIFT;
> obj->pages = drm_malloc_ab(num, sizeof(*obj->pages));
> [...]
> for (i = 0; i < num; ++i) {
> obj->pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO);
> [...]
> obj->vmapping = vmap(obj->pages, num, 0, PAGE_KERNEL);
> [...]
> }
>
>
> The simpledrm driver has this set_config:
>
> static int sdrm_crtc_set_config(struct drm_mode_set *set)
> {
> struct drm_device *ddev;
> struct sdrm_device *sdrm;
> struct sdrm_framebuffer *fb;
> [...]
> ddev = set->crtc->dev;
> sdrm = ddev->dev_private;
> [...]
> fb = to_sdrm_fb(set->fb);
> [...]
> if (set->mode->hdisplay != sdrm->fb_width ||
> set->mode->vdisplay != sdrm->fb_height)
> return -EINVAL;
> if (fb->base.width <= set->x ||
> fb->base.height <= set->y ||
> fb->base.width - set->x < sdrm->fb_width ||
> fb->base.height - set->y < sdrm->fb_height)
> return -EINVAL;
> [...]
> }
>
> Do I need to perform any of these checks in the new check function?
> And if so, how?

Instead of set->(mode|x|y) look at crtc_state->(mode|x|y), and instead
of fb look at plane_state->fb. Everything else should be checked with
the default plane helper checks the simple pipe helpers already do.
-Daniel

> static int sdrm_display_pipe_check(struct drm_simple_display_pipe *pipe,
>struct drm_plane_state *plane_state,
>struct drm_crtc_state *crtc_state)
> {
> struct sdrm_device *sdrm = pipe_to_sdrm(pipe);
>
> return 0;
> }
>
>
> Noralf.
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFC 0/3] drm: Add DRM text mode

[Noralf Trønnes]

Den 30.07.2016 17:48, skrev Noralf Trønnes:
>
> Den 29.07.2016 10:23, skrev Daniel Vetter:
>> Actually adding David.
>> -Daniel
>>
>> On Fri, Jul 29, 2016 at 10:20:51AM +0200, Daniel Vetter wrote:
>>> On Thu, Jul 28, 2016 at 04:15:04PM +0200, Noralf Trønnes wrote:
 This patchset explores the idea of adding a DRM text mode
 (like VGA text mode) to get an alternative to fbcon/fbdev.

 David Hermann has done alot of work on a fbcon replacement:
 - drm: add kernel-log renderer (Mar 2014)[1]
 - kmscon:
development started Nov 2011
added to systemd Oct 2014
removed from systemd Jul 2015[2]

 Since this work seems to have stalled, I propose an alternative 
 solution
 to this problem that will also give VT console support while we're 
 waiting
 for a userspace console.

 The idea is that the driver provides a modeset like with the fbdev 
 emulation
 code, and from this a text buffer representation is made. The 
 console code
 can now write to this text buffer and ask for the text buffer to be
 flushed/rendered to the pixel buffer.

 In this hack/implementation of the idea, I have just hijacked a CMA 
 backed
 fbdev framebuffer to keep it simple.
 I have reused the default buffer format that VT uses.
 Getting panic handling to actually work, seems to be a challenge as 
 Daniel
 describes on the DRMJanitors page[3].

 Is this idea of a DRM text mode worth developing further?
>>> I guess some simpler drm console with vt support which would allow 
>>> us to
>>> get rid of fbdev could make sense. And there's definitely going to be a
>>> lot of overlap with a full userspace solution using something like 
>>> kmscon.
>>>
>>> But we can't just add a new drm text console, there's a pile of prep 
>>> work
>>> needed that David started for either approach:
>>> - Nuking fbdev means no more fbdev drivers for firmware consoles 
>>> (uboot,
>>>uefi, vga, ...). The simpledrm driver would cover this, would be 
>>> great
>>>to get that landed (especially now that we have the simple pipe
>>>helpers!).
>
> I have rebased simpledrm on drm_simple_display_pipe and have it 
> working on
> a Raspberry Pi. modetest gives me a wrong picture, but that is probably
> because of some wrong format conversion since fbdev using the native
> rgb565 format works fine.
>
> I could finish this up and send a patch unless David is working on 
> something?
>
> I have used this version of simpledrm: [PATCH 09/11] drm: add 
> SimpleDRM driver
> https://lists.freedesktop.org/archives/dri-devel/2014-January/052594.html
>

I have solved the format conversion problem.

Is there any reason why simpledrm can't use drm_gem_cma_helper?
This is how it allocates memory:

int sdrm_gem_get_pages(struct sdrm_gem_object *obj)
{
[...]
 num = obj->base.size >> PAGE_SHIFT;
 obj->pages = drm_malloc_ab(num, sizeof(*obj->pages));
[...]
 for (i = 0; i < num; ++i) {
 obj->pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO);
[...]
 obj->vmapping = vmap(obj->pages, num, 0, PAGE_KERNEL);
[...]
}


The simpledrm driver has this set_config:

static int sdrm_crtc_set_config(struct drm_mode_set *set)
{
 struct drm_device *ddev;
 struct sdrm_device *sdrm;
 struct sdrm_framebuffer *fb;
[...]
 ddev = set->crtc->dev;
 sdrm = ddev->dev_private;
[...]
 fb = to_sdrm_fb(set->fb);
[...]
 if (set->mode->hdisplay != sdrm->fb_width ||
 set->mode->vdisplay != sdrm->fb_height)
 return -EINVAL;
 if (fb->base.width <= set->x ||
 fb->base.height <= set->y ||
 fb->base.width - set->x < sdrm->fb_width ||
 fb->base.height - set->y < sdrm->fb_height)
 return -EINVAL;
[...]
}

Do I need to perform any of these checks in the new check function?
And if so, how?

static int sdrm_display_pipe_check(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state,
struct drm_crtc_state *crtc_state)
{
 struct sdrm_device *sdrm = pipe_to_sdrm(pipe);

 return 0;
}


Noralf.

[RFC 0/3] drm: Add DRM text mode

[Noralf Trønnes]

Den 29.07.2016 10:23, skrev Daniel Vetter:
> Actually adding David.
> -Daniel
>
> On Fri, Jul 29, 2016 at 10:20:51AM +0200, Daniel Vetter wrote:
>> On Thu, Jul 28, 2016 at 04:15:04PM +0200, Noralf Trønnes wrote:
>>> This patchset explores the idea of adding a DRM text mode
>>> (like VGA text mode) to get an alternative to fbcon/fbdev.
>>>
>>> David Hermann has done alot of work on a fbcon replacement:
>>> - drm: add kernel-log renderer (Mar 2014)[1]
>>> - kmscon:
>>>development started Nov 2011
>>>added to systemd Oct 2014
>>>removed from systemd Jul 2015[2]
>>>
>>> Since this work seems to have stalled, I propose an alternative solution
>>> to this problem that will also give VT console support while we're waiting
>>> for a userspace console.
>>>
>>> The idea is that the driver provides a modeset like with the fbdev emulation
>>> code, and from this a text buffer representation is made. The console code
>>> can now write to this text buffer and ask for the text buffer to be
>>> flushed/rendered to the pixel buffer.
>>>
>>> In this hack/implementation of the idea, I have just hijacked a CMA backed
>>> fbdev framebuffer to keep it simple.
>>> I have reused the default buffer format that VT uses.
>>> Getting panic handling to actually work, seems to be a challenge as Daniel
>>> describes on the DRMJanitors page[3].
>>>
>>> Is this idea of a DRM text mode worth developing further?
>> I guess some simpler drm console with vt support which would allow us to
>> get rid of fbdev could make sense. And there's definitely going to be a
>> lot of overlap with a full userspace solution using something like kmscon.
>>
>> But we can't just add a new drm text console, there's a pile of prep work
>> needed that David started for either approach:
>> - Nuking fbdev means no more fbdev drivers for firmware consoles (uboot,
>>uefi, vga, ...). The simpledrm driver would cover this, would be great
>>to get that landed (especially now that we have the simple pipe
>>helpers!).

I have rebased simpledrm on drm_simple_display_pipe and have it working on
a Raspberry Pi. modetest gives me a wrong picture, but that is probably
because of some wrong format conversion since fbdev using the native
rgb565 format works fine.

I could finish this up and send a patch unless David is working on 
something?

I have used this version of simpledrm: [PATCH 09/11] drm: add SimpleDRM 
driver
https://lists.freedesktop.org/archives/dri-devel/2014-January/052594.html

>> - One nice benefit of fbdev is that it automatically gets rid of these
>>firmware-based display drivers when the real driver loads. Some drivers
>>do this properly even when fbdev isn't enabled (see i915_kick_out_vgacon
>>and i915_kick_out_firmware_fb), but pretty much all others fail in some
>>way or the other. David also had some code (iirc as part of simpledrm)
>>to solve this issue.
>>
>> - I think we need more than rbg565 render support, iirc David also had
>>some work in that area.
>>
>> - None of these approaches has a good answer yet to the configuration
>>question. For a full VT I think we definitely should share the setup
>>logic with the fbdev emulation code to make it useful, but as describe
>>in the DRMJanitors page handlings panics is an entierly different
>>problem.
>>
>> Definitely coordinate with David Herrmann here too, since if we do
>> something in this area it should be widely supported.
>>
>> Aside: Where's the pull request for your driver? ;-)

I have been working on tinydrm for 6 months straight now and it wasn't fun
anymore. So I figured this was a good time to take a break from it and do
something else for a while :-)


Noralf.

>> Cheers, Daniel
>>
>>>
>>> Noralf.
>>>
>>> [1] https://lwn.net/Articles/589858/
>>> [2] https://github.com/systemd/systemd/pull/747
>>> [3] https://www.x.org/wiki/DRMJanitors/#makepanichandlingwork
>>>
>>>
>>> Noralf Trønnes (3):
>>>drm: Add support for text framebuffer
>>>drm/text: Add panic and boot console support
>>>drm/text: Add VT console support
>>>
>>>   drivers/gpu/drm/Makefile|   1 +
>>>   drivers/gpu/drm/drm-text/Makefile   |   5 +
>>>   drivers/gpu/drm/drm-text/drm-text-buffer.c  | 340 
>>> 
>>>   drivers/gpu/drm/drm-text/drm-text-console.c | 205 +
>>>   drivers/gpu/drm/drm-text/drm-text-debugfs.c | 295 
>>>   drivers/gpu/drm/drm-text/drm-text-vt.c  | 197 
>>>   drivers/gpu/drm/drm-text/drm-text.h |  99 
>>>   7 files changed, 1142 insertions(+)
>>>   create mode 100644 drivers/gpu/drm/drm-text/Makefile
>>>   create mode 100644 drivers/gpu/drm/drm-text/drm-text-buffer.c
>>>   create mode 100644 drivers/gpu/drm/drm-text/drm-text-console.c
>>>   create mode 100644 drivers/gpu/drm/drm-text/drm-text-debugfs.c
>>>   create mode 100644 drivers/gpu/drm/drm-text/drm-text-vt.c
>>>   create mode 100644 

[RFC 0/3] drm: Add DRM text mode

[Daniel Vetter]

Actually adding David.
-Daniel

On Fri, Jul 29, 2016 at 10:20:51AM +0200, Daniel Vetter wrote:
> On Thu, Jul 28, 2016 at 04:15:04PM +0200, Noralf Trønnes wrote:
> > This patchset explores the idea of adding a DRM text mode
> > (like VGA text mode) to get an alternative to fbcon/fbdev.
> > 
> > David Hermann has done alot of work on a fbcon replacement:
> > - drm: add kernel-log renderer (Mar 2014)[1]
> > - kmscon:
> >   development started Nov 2011
> >   added to systemd Oct 2014
> >   removed from systemd Jul 2015[2]
> > 
> > Since this work seems to have stalled, I propose an alternative solution
> > to this problem that will also give VT console support while we're waiting
> > for a userspace console.
> > 
> > The idea is that the driver provides a modeset like with the fbdev emulation
> > code, and from this a text buffer representation is made. The console code
> > can now write to this text buffer and ask for the text buffer to be
> > flushed/rendered to the pixel buffer.
> > 
> > In this hack/implementation of the idea, I have just hijacked a CMA backed
> > fbdev framebuffer to keep it simple.
> > I have reused the default buffer format that VT uses.
> > Getting panic handling to actually work, seems to be a challenge as Daniel
> > describes on the DRMJanitors page[3].
> > 
> > Is this idea of a DRM text mode worth developing further?
> 
> I guess some simpler drm console with vt support which would allow us to
> get rid of fbdev could make sense. And there's definitely going to be a
> lot of overlap with a full userspace solution using something like kmscon.
> 
> But we can't just add a new drm text console, there's a pile of prep work
> needed that David started for either approach:
> - Nuking fbdev means no more fbdev drivers for firmware consoles (uboot,
>   uefi, vga, ...). The simpledrm driver would cover this, would be great
>   to get that landed (especially now that we have the simple pipe
>   helpers!).
> 
> - One nice benefit of fbdev is that it automatically gets rid of these
>   firmware-based display drivers when the real driver loads. Some drivers
>   do this properly even when fbdev isn't enabled (see i915_kick_out_vgacon
>   and i915_kick_out_firmware_fb), but pretty much all others fail in some
>   way or the other. David also had some code (iirc as part of simpledrm)
>   to solve this issue.
> 
> - I think we need more than rbg565 render support, iirc David also had
>   some work in that area.
> 
> - None of these approaches has a good answer yet to the configuration
>   question. For a full VT I think we definitely should share the setup
>   logic with the fbdev emulation code to make it useful, but as describe
>   in the DRMJanitors page handlings panics is an entierly different
>   problem.
> 
> Definitely coordinate with David Herrmann here too, since if we do
> something in this area it should be widely supported.
> 
> Aside: Where's the pull request for your driver? ;-)
> 
> Cheers, Daniel
> 
> > 
> > 
> > Noralf.
> > 
> > [1] https://lwn.net/Articles/589858/
> > [2] https://github.com/systemd/systemd/pull/747
> > [3] https://www.x.org/wiki/DRMJanitors/#makepanichandlingwork
> > 
> > 
> > Noralf Trønnes (3):
> >   drm: Add support for text framebuffer
> >   drm/text: Add panic and boot console support
> >   drm/text: Add VT console support
> > 
> >  drivers/gpu/drm/Makefile|   1 +
> >  drivers/gpu/drm/drm-text/Makefile   |   5 +
> >  drivers/gpu/drm/drm-text/drm-text-buffer.c  | 340 
> > 
> >  drivers/gpu/drm/drm-text/drm-text-console.c | 205 +
> >  drivers/gpu/drm/drm-text/drm-text-debugfs.c | 295 
> >  drivers/gpu/drm/drm-text/drm-text-vt.c  | 197 
> >  drivers/gpu/drm/drm-text/drm-text.h |  99 
> >  7 files changed, 1142 insertions(+)
> >  create mode 100644 drivers/gpu/drm/drm-text/Makefile
> >  create mode 100644 drivers/gpu/drm/drm-text/drm-text-buffer.c
> >  create mode 100644 drivers/gpu/drm/drm-text/drm-text-console.c
> >  create mode 100644 drivers/gpu/drm/drm-text/drm-text-debugfs.c
> >  create mode 100644 drivers/gpu/drm/drm-text/drm-text-vt.c
> >  create mode 100644 drivers/gpu/drm/drm-text/drm-text.h
> > 
> > --
> > 2.8.2
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC 0/3] drm: Add DRM text mode

[Daniel Vetter]

On Thu, Jul 28, 2016 at 04:15:04PM +0200, Noralf Trønnes wrote:
> This patchset explores the idea of adding a DRM text mode
> (like VGA text mode) to get an alternative to fbcon/fbdev.
> 
> David Hermann has done alot of work on a fbcon replacement:
> - drm: add kernel-log renderer (Mar 2014)[1]
> - kmscon:
>   development started Nov 2011
>   added to systemd Oct 2014
>   removed from systemd Jul 2015[2]
> 
> Since this work seems to have stalled, I propose an alternative solution
> to this problem that will also give VT console support while we're waiting
> for a userspace console.
> 
> The idea is that the driver provides a modeset like with the fbdev emulation
> code, and from this a text buffer representation is made. The console code
> can now write to this text buffer and ask for the text buffer to be
> flushed/rendered to the pixel buffer.
> 
> In this hack/implementation of the idea, I have just hijacked a CMA backed
> fbdev framebuffer to keep it simple.
> I have reused the default buffer format that VT uses.
> Getting panic handling to actually work, seems to be a challenge as Daniel
> describes on the DRMJanitors page[3].
> 
> Is this idea of a DRM text mode worth developing further?

I guess some simpler drm console with vt support which would allow us to
get rid of fbdev could make sense. And there's definitely going to be a
lot of overlap with a full userspace solution using something like kmscon.

But we can't just add a new drm text console, there's a pile of prep work
needed that David started for either approach:
- Nuking fbdev means no more fbdev drivers for firmware consoles (uboot,
  uefi, vga, ...). The simpledrm driver would cover this, would be great
  to get that landed (especially now that we have the simple pipe
  helpers!).

- One nice benefit of fbdev is that it automatically gets rid of these
  firmware-based display drivers when the real driver loads. Some drivers
  do this properly even when fbdev isn't enabled (see i915_kick_out_vgacon
  and i915_kick_out_firmware_fb), but pretty much all others fail in some
  way or the other. David also had some code (iirc as part of simpledrm)
  to solve this issue.

- I think we need more than rbg565 render support, iirc David also had
  some work in that area.

- None of these approaches has a good answer yet to the configuration
  question. For a full VT I think we definitely should share the setup
  logic with the fbdev emulation code to make it useful, but as describe
  in the DRMJanitors page handlings panics is an entierly different
  problem.

Definitely coordinate with David Herrmann here too, since if we do
something in this area it should be widely supported.

Aside: Where's the pull request for your driver? ;-)

Cheers, Daniel

> 
> 
> Noralf.
> 
> [1] https://lwn.net/Articles/589858/
> [2] https://github.com/systemd/systemd/pull/747
> [3] https://www.x.org/wiki/DRMJanitors/#makepanichandlingwork
> 
> 
> Noralf Trønnes (3):
>   drm: Add support for text framebuffer
>   drm/text: Add panic and boot console support
>   drm/text: Add VT console support
> 
>  drivers/gpu/drm/Makefile|   1 +
>  drivers/gpu/drm/drm-text/Makefile   |   5 +
>  drivers/gpu/drm/drm-text/drm-text-buffer.c  | 340 
> 
>  drivers/gpu/drm/drm-text/drm-text-console.c | 205 +
>  drivers/gpu/drm/drm-text/drm-text-debugfs.c | 295 
>  drivers/gpu/drm/drm-text/drm-text-vt.c  | 197 
>  drivers/gpu/drm/drm-text/drm-text.h |  99 
>  7 files changed, 1142 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm-text/Makefile
>  create mode 100644 drivers/gpu/drm/drm-text/drm-text-buffer.c
>  create mode 100644 drivers/gpu/drm/drm-text/drm-text-console.c
>  create mode 100644 drivers/gpu/drm/drm-text/drm-text-debugfs.c
>  create mode 100644 drivers/gpu/drm/drm-text/drm-text-vt.c
>  create mode 100644 drivers/gpu/drm/drm-text/drm-text.h
> 
> --
> 2.8.2
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC 0/3] drm: Add DRM text mode

[Noralf Trønnes]

This patchset explores the idea of adding a DRM text mode
(like VGA text mode) to get an alternative to fbcon/fbdev.

David Hermann has done alot of work on a fbcon replacement:
- drm: add kernel-log renderer (Mar 2014)[1]
- kmscon:
  development started Nov 2011
  added to systemd Oct 2014
  removed from systemd Jul 2015[2]

Since this work seems to have stalled, I propose an alternative solution
to this problem that will also give VT console support while we're waiting
for a userspace console.

The idea is that the driver provides a modeset like with the fbdev emulation
code, and from this a text buffer representation is made. The console code
can now write to this text buffer and ask for the text buffer to be
flushed/rendered to the pixel buffer.

In this hack/implementation of the idea, I have just hijacked a CMA backed
fbdev framebuffer to keep it simple.
I have reused the default buffer format that VT uses.
Getting panic handling to actually work, seems to be a challenge as Daniel
describes on the DRMJanitors page[3].

Is this idea of a DRM text mode worth developing further?


Noralf.

[1] https://lwn.net/Articles/589858/
[2] https://github.com/systemd/systemd/pull/747
[3] https://www.x.org/wiki/DRMJanitors/#makepanichandlingwork


Noralf Trønnes (3):
  drm: Add support for text framebuffer
  drm/text: Add panic and boot console support
  drm/text: Add VT console support

 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/drm-text/Makefile   |   5 +
 drivers/gpu/drm/drm-text/drm-text-buffer.c  | 340 
 drivers/gpu/drm/drm-text/drm-text-console.c | 205 +
 drivers/gpu/drm/drm-text/drm-text-debugfs.c | 295 
 drivers/gpu/drm/drm-text/drm-text-vt.c  | 197 
 drivers/gpu/drm/drm-text/drm-text.h |  99 
 7 files changed, 1142 insertions(+)
 create mode 100644 drivers/gpu/drm/drm-text/Makefile
 create mode 100644 drivers/gpu/drm/drm-text/drm-text-buffer.c
 create mode 100644 drivers/gpu/drm/drm-text/drm-text-console.c
 create mode 100644 drivers/gpu/drm/drm-text/drm-text-debugfs.c
 create mode 100644 drivers/gpu/drm/drm-text/drm-text-vt.c
 create mode 100644 drivers/gpu/drm/drm-text/drm-text.h

--
2.8.2