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.
