Video Hackfest conclusions
Hi, As you may be aware, we held a video hackfest last week in Barcelona. Developers met to discuss how best to improve GPU support for video applications. See http://gstreamer.freedesktop.org/wiki/VideoHackfest for more details. In particular, you might be interested in the notes some people took while the hackfest was going on. These can be found at http://gstreamer.freedesktop.org/wiki/VideoHackfest/Notes What follows is the results we arrived at after the hackfest. They are taken from http://gstreamer.freedesktop.org/wiki/VideoHackfest/Conclusions but certainly deserve wide circulation. We're interested in any comments (or questions) you might have about them, so please don't heistate to reply. If you do reply, please make sure to reduce the recipient list appropriately. Cheers, Benjamin, on behalf of all hackfest paticipants. == YUV in pixman == It has been a goal for a while to make video a first-class citizen in the image stack. A concrete API proposal on how to integrate video into pixman was reached and reviewed. Links: * http://gstreamer.freedesktop.org/wiki/VideoHackfest/YCbCr_Formats * http://gstreamer.freedesktop.org/wiki/VideoHackfest/pixman Actions: * GStreamer developers to provide a specification of important YUV formats * Write implementation == YUV in Cairo == To make it easy for applications to use these different formats, the Cairo API needs to be extended to allow them. A proposal does exist and has been reviewed, details need to be finalized. Links: * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Cairo Actions: * Finalize proposal * Write implementation == locking in Cairo == GStreamer takes a lot of freedom in deciding which threads to schedule elements in. Most hardware backends however require proper serialization of commands. The current gst-plugins-cairo and gst-plugins-gl code provide different, but ugly ways to achieve this. Cairo's internal thread safety guarantees match these requirements very well. But the different Cairo backends don't always keep these guarantees. Interaction with these locking mechanisms from outside applications is not possible yet either. Links: * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Cairo Actions: * Improve Cairo backend implementations, in particular X11 and GL * Expose Cairo's locking API to allow interaction with it * Write testcases to squash bugs == locking in Mesa == The GLX specification does not allow binding the same GLX context in multiple threads at the same time. This is a requirement for both Cairo's and GStreamer's threading model. An extension was proposed and initial code developed to support this requirement in the same way as Apple's GL does by default. Windows does not support this and would require potentially expensive fallback code. Links: * http://people.freedesktop.org/~anholt/MESA_multithread_makecurrent.spec Actions: * Get review for suggested extension and include it in future Mesa releases * Make Windows developers investigate the situation == switch GStreamer to Cairo as default video transport model == The current approach to handling video in GStreamer is very outdated. It does not allow hw-accelerated buffers nor does it provide a unified API to modify video buffers, which leads to fragmentation and duplication. It was agreed that using Cairo to provide an abstraction as a drawing API and abstraction over different backends was a good idea. Links: * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Notes * http://cgit.freedesktop.org/~company/gst-plugins-cairo Actions: * Rework gst-plugins-cairo to match improvements listed in previous points * Get more review on API and to avoid regressions * Merge into gst-plugins-base * Switch plugins gradually to use new Cairo code == gst-plugins-gl == The general consensus was that gst-plugins-gl is a hack. It was necessary in the past to get things to work, but is not a good way forward. However, the functionality or performance provided by the current elements needs to continue working. Developers shared the opinion that gst-plugins-cairo with cairo-gl surfaces is the best way to achieve this. Links: * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Notes Actions: * Get review of cairo-gl/gst-plugins-cairo code from gst-plugins-gl developers * Port gst-plugins-gl elements to use Cairo early to ensure required features are available == XRenderPutImage == Currently there is no way to upload video data to the X server for later use. The XV extension is not sufficient for anything more complicated than a simple video player. Links: * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Cairo Actions: * Figure out the best way to move YUV data into hw-accelerated Cairo surfaces (GL vs X) * Possibly draft an extension to XRender to handle this in the no-GL case == JIT in Pixman == ORC was investigated as a potential JIT for pixman. A lot of talk has happened, but no clear conclusions were reached. The idea to share a JIT
Re: Ctrl+alt_bksp
On 11/24/09 01:50, Russell Shaw wrote: > Vandana Vuthoo wrote: >> Hi, >> I am having Xserver as v 1.6 on my intel atom board, some how ctrl + >> alt + bksp doesnot restart my X server, Even setting setxkbmap -option >> terminate:ctrl-alt-bksp in xorg.conf doesnot help. >> Please provide you inputs. > > Underscores? > > setxkbmap -option "terminate:ctrl_alt_bksp" > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > that or they decided under security reason's to move around the code. Justin P. Mattock ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xmodmap] Problem with e and n
On Monday 23 November 2009 23:15:21 walt wrote:
> On 11/23/2009 02:04 AM, Dirk Wallenstein wrote:
> > On Sunday 22 November 2009 23:35:29 walt wrote:
> >> I've mapped my CapsLock key to a plain Shift_L key, using your
> >> instructions.
> >> Here is the output of xev (note the keycode is 66):
> >>
> >> KeyPress event, serial 30, synthetic NO, window 0x201,
> >> root 0x189, subw 0x0, time 35504647, (136,79), root:(140,822),
> >> state 0x0, keycode 66 (keysym 0xffe1, Shift_L), same_screen YES,
> >> XKeysymToKeycode returns keycode: 50
> >> XLookupString gives 0 bytes:
> >> XmbLookupString gives 0 bytes:
> >> XFilterEvent returns: False
> >>
> >> That part is wonderful, but pressing the Caps Lock key doesn't create upper
> >> case letters, but pressing the Shift key does.
> >>
> >> Here is the line that I changed in the .xkb file:
> >> key { [ Shift_L ] };
> >>
> >> What have I missed?
> >
> >
> > For modifiers, you have to change the modifier_map entry.
> >
> > Currently, it will look like this:
> > modifier_map Lock { };
> >
> > Change it to:
> > modifier_map Shift { };
>
> Yes! The wicked CapsLock witch is dead :o) Thank you.
>
> BTW, I was able to modify the default pc101 easily enough in duttulm to my
> desired configuration, but now I have the resulting XML file in ~/.duttulm
> and I don't know what to do with it. What comes next?
Nothing, yet, I'm afraid. Duttulm is under development and it will
take some time until it is ready. But then, you will be able to do the
reconfiguration you did, and much more, through a nice GUI.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Ctrl+alt_bksp
Vandana Vuthoo wrote: > Hi, > I am having Xserver as v 1.6 on my intel atom board, some how ctrl + > alt + bksp doesnot restart my X server, Even setting setxkbmap -option > terminate:ctrl-alt-bksp in xorg.conf doesnot help. > Please provide you inputs. Underscores? setxkbmap -option "terminate:ctrl_alt_bksp" ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Adding borders do display (resolution problems)
My laptop (with intel-based graphics) has a matrix with a 1280x800 resolution. Both at home and at work I also use additional monitors, which both do not support such resolution - they both can display 1280x1024 pixels. If I want to achieve such situation, that I have the same screens on both displays, I vahe to use --scale option with xrandr and it works - but the picture on external screen is stretched and looks kind of weird (aspect is not preserved). In the same time, when I start my system, after the i915 module is loaded (with KMS on), the external display is also turned on and displays exactly the same picture as the biult-in one. I just have a 224 pixel high margin on the bottom, but the aspect is correct. Is it possible to obtain a similar situation using xrandr (a certain combination of parameters or something)? I just want to use just a part of the 1280x1024 screen to display 1280x800 desktop with the same aspect ratio as on the built-in matrix. -- Łukasz Maśko GG: 2441498_o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafrykańskie słowo oznaczające "Nie umiem zainstalować Debiana" ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
