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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
