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

[Daniel Vetter]

On Mon, Aug 1, 2016 at 12:50 PM, Noralf Trønnes <noralf at tronnes.org> 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