Hello, On Friday, April 01, 2011 10:49 AM Jonghun Han wrote: > On Wednesday, March 30, 2011 4:01 PM Marek Szyprowski wrote: > > Hello, > > > > On V4L2 brainstorming meeting in Warsaw we discussed the need of a > > framebuffer userspace interface for video output devices. Such > > framebuffer interface is aimed mainly for legacy applications and/or > > interoperatibility with Xfbdev. > > > > I proposed to give the idea of generic fb-on-top-of-video-node a second > > try, now using the power of videobuf2. > > > > This short patch series demonstrates that this approach is possible. We > > succesfully implemented a framebuffer emulator and tested it with > > s5p-hdmi driver on Samsung Exynos4 platform. > > > > This initial version provides a basic non-accelerated framebuffer > > device. The emulation is started on the first open of the framebuffer > > device and stopped on last close. The framebuffer boots in 'blanked' > > mode, so one also needs to make a call to blank ioctl (with > > FB_BLANK_UNBLANK argument) to enable video output. > > > > We successfully managed to get vanilla Xfbdev server working on top of > > it without ANY changes in X server sources. > > > > The framebuffer resolution and pixel format is autoconfigured from the > > parameters of the corresponding video output node. One can use v4l2-ctrl > > (or similar) tool to select pixel format, resolution, output, etc (and > > in the near future also the composition on the target video device). > > > > There a few requirements for the video output driver: > > 1. support for single-buffering mode > > 2. support for videoc_ioctl interface (this might change in the future) > > 3. use memory allocator that allows coherent mappings (mmaped framebuffer > > will be accessed by application while it is displayed by dma engine). > > > > The changes that are needed in the video output driver are really > > simple. Mainly one need to add just a call to vb2_fb_register(q, vfd) > > and vb2_fb_register(fb) functions. > > > > The future versions might aslo include the following features: > > - vsync event translation into WAIT_VSYNC framebuffer ioctl > > - support for frame buffer panning with upcoming S_COMPOSE ioctl > > > > As I know, the panning is different from upcoming S_COMPOSE. > The panning selects the frame buffer area which will be read by display > controller to support virtual screen feature. > But as I remember, the S_COMPOSE is related in positioning on the display > device like HDMI. > IMO, VIDIOC_S_EXTCROP makes sense for panning. Right, I was thinking of S_EXTCROP but I wrote S_COMPOSE. I'm sorry for the confusion. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
