On Mon, Aug 1, 2016 at 12:50 PM, Noralf Trønnes <noralf@xxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
