Re: The All-Singing, All-Dancing XCompMGR
On Fri, Apr 30, 2010 at 22:35, Jon Nettleton jon.nettle...@gmail.com wrote: I think our next steps should be to: * quantify the memory difference (both total and per-window) against not running xcompmgr. We were already running with the composite X extension on, so I think the increase may be small. * work out whether we think the frame pieces drop shadow, and drop shadow in general, are an improvement -- we should ask the Sugar Design Team for their opinion on this too. Jon N, any opinions from the openchrome end on turning on xcompmgr? Currently compositing on the VX855 with openchrome would work, but is extemely inefficient. The openchrome support for the VX855 only supports XAA until we get DRI and DMA sorted out. Compositing on XAA is really inefficient as only System Memory to VRAM actions are accelerated by the RENDER extension. Overall compositing is visually a nice improvement, but almost always at a cost of CPU and power. I also think xcompmgr is not the right piece of software. It is really old and missing a lot of the love needed for a good compositing manager to work seamlessly. Mainly it is missing un-redirecting fullscreen windows and overlays causing video playback to be quite expensive, and OpenGL to be unreliable. Back when Thomas first wrote EXA support for the openchrome we found that the bare minimum you needed for descent compositing performance was 64MB of video ram. This is doable but we also have to realize we are at a disadvantage because we run at a relative high resolution 1200x900. If we were going the compositing route I would probably suggest the project look into using a simple compositing window manager like XFWM from the XFCE project. Their code was originally an import of xcompmgr, but they have done a great job improving it over the years. But I think that is another conversation entirely. We could reuse the work done in Sugar 0.86 when we moved to metacity from matchbox. Or just use metacity which is also a compositing windowm manager. Regards, Tomeu Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The All-Singing, All-Dancing XCompMGR
On Mon, May 3, 2010 at 8:17 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Fri, Apr 30, 2010 at 22:35, Jon Nettleton jon.nettle...@gmail.com wrote: I think our next steps should be to: * quantify the memory difference (both total and per-window) against not running xcompmgr. We were already running with the composite X extension on, so I think the increase may be small. * work out whether we think the frame pieces drop shadow, and drop shadow in general, are an improvement -- we should ask the Sugar Design Team for their opinion on this too. Jon N, any opinions from the openchrome end on turning on xcompmgr? Currently compositing on the VX855 with openchrome would work, but is extemely inefficient. The openchrome support for the VX855 only supports XAA until we get DRI and DMA sorted out. Compositing on XAA is really inefficient as only System Memory to VRAM actions are accelerated by the RENDER extension. Overall compositing is visually a nice improvement, but almost always at a cost of CPU and power. I also think xcompmgr is not the right piece of software. It is really old and missing a lot of the love needed for a good compositing manager to work seamlessly. Mainly it is missing un-redirecting fullscreen windows and overlays causing video playback to be quite expensive, and OpenGL to be unreliable. Back when Thomas first wrote EXA support for the openchrome we found that the bare minimum you needed for descent compositing performance was 64MB of video ram. This is doable but we also have to realize we are at a disadvantage because we run at a relative high resolution 1200x900. If we were going the compositing route I would probably suggest the project look into using a simple compositing window manager like XFWM from the XFCE project. Their code was originally an import of xcompmgr, but they have done a great job improving it over the years. But I think that is another conversation entirely. We could reuse the work done in Sugar 0.86 when we moved to metacity from matchbox. Or just use metacity which is also a compositing windowm manager. Or mutter which is the replacement to metacity for gnome 3 so should be a reasonably easy swap from metacity and is used by gnome-shell and moblin/(meego). Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The All-Singing, All-Dancing XCompMGR
We could reuse the work done in Sugar 0.86 when we moved to metacity from matchbox. Or just use metacity which is also a compositing windowm manager. Or mutter which is the replacement to metacity for gnome 3 so should be a reasonably easy swap from metacity and is used by gnome-shell and moblin/(meego). Unfortunately we cannot switch to mutter as that only uses Clutter as the compositing backend. I know this because I am the person that patched the XRender compositing engine out of the source :-( This means that mutter requires a 3-d accelerated graphics card. This may be possible for the VX855 XO 1.5's but I don't think the XO1's would be able to handle this requirement. The ARM based chips might be able to with Clutter using the OpenGL ES backend but I am pretty sure nobody has tested this yet. Metacity is definitely an option, but any enhancements done to it would need to be maintained in an OLPC/Sugar specific branch. Choosing this option would definitely need some time invested into running down some memory leaks and optimizing the engine. Compositing in metacity was always an afterthought and never 100% got the love it needed to be used full time. All this is fixable, just won't be done by the GNOME guys. Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The All-Singing, All-Dancing XCompMGR
On Mon, May 3, 2010 at 15:34, Jon Nettleton jon.nettle...@gmail.com wrote: We could reuse the work done in Sugar 0.86 when we moved to metacity from matchbox. Or just use metacity which is also a compositing windowm manager. Or mutter which is the replacement to metacity for gnome 3 so should be a reasonably easy swap from metacity and is used by gnome-shell and moblin/(meego). Unfortunately we cannot switch to mutter as that only uses Clutter as the compositing backend. I know this because I am the person that patched the XRender compositing engine out of the source :-( This means that mutter requires a 3-d accelerated graphics card. This may be possible for the VX855 XO 1.5's but I don't think the XO1's would be able to handle this requirement. The ARM based chips might be able to with Clutter using the OpenGL ES backend but I am pretty sure nobody has tested this yet. Metacity is definitely an option, but any enhancements done to it would need to be maintained in an OLPC/Sugar specific branch. Choosing this option would definitely need some time invested into running down some memory leaks and optimizing the engine. Compositing in metacity was always an afterthought and never 100% got the love it needed to be used full time. All this is fixable, just won't be done by the GNOME guys. Ah, forgot to mention that if we are thinking seriously about using composition, the best place to do composition management may be the Sugar Shell, as it knows quit a bit about the window management but also some Sugar-specific stuff. It could be as simple as redirecting every top level window, but we could do tricks such as only keeping redirected the root window and the last 2 activities that had the focus, if we want to reduce memory usage. I had at some point code to do this but it was some years ago and would take a bit finding it. I remember I was calling some of these calls through ctypes: http://linux.die.net/man/3/xcomposite Maybe just XCompositeRedirectSubwindows and XCompositeUnredirectSubwindows. Regards, Tomeu Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The All-Singing, All-Dancing XCompMGR
I had at some point code to do this but it was some years ago and would take a bit finding it. I remember I was calling some of these calls through ctypes: http://linux.die.net/man/3/xcomposite Maybe just XCompositeRedirectSubwindows and XCompositeUnredirectSubwindows. That could definitely work. I would take a look at the work done by the Cairo Composite Manager guys, http://cairo-compmgr.tuxfamily.org/ as well. Their project is quite mature and could somehow be helpful to Sugar as it has some cairo based pieces already. Ultimately it would be great to see Sugar be able to exist as a WM plugin to mutter like gnome-shell or moblin/meego but currently it just takes too much horsepower to be a viable alternative. Of course if you want to test the compositing performance/power usage on the XO 1.5 you can do so from the GNOME environment. gconftool-2 -s '/apps/metacity/general/compositing_manager' --type bool true and then gconftool-2 -s '/apps/metacity/general/compositing_manager' --type bool false to turn it back off. It generally works fine, however most the acceleration options are falling back through to sofware acceleration on the CPU. Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Review pull request: dracut-modules-olpc
On 30 April 2010 19:39, Martin Langhoff martin.langh...@gmail.com wrote: Fair enough. One of the problems is that normally the expiry check is done inside bitfrost lib and the code there only respects the system clock. So it's a bit messy. Rework bitfrost libs (with impact on users if the lib) or implement a bit of code that knows enough about the sig format to find out all the expiry dates and picks the lowest one... If you really want it, I'll try find the time, though it's... messy. It seems like a pretty important security hole to me. We should do this stuff properly. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO 1.5 frequency scaling
Hi all, I have been wondering for some time how are you controlling the frequency of the C7 processor in Fedora. Is this being done in the background by openfirmware or some other place where it is not visible. I would like to test it's effect on battery life and to know if power management needs to be done in another way for other distros. Also, similarly to the XO 1, can one do something with openfirmware to test overclocking and not just underclocking, as has been mentioned in some previous e-mails. Best regards, Tiago ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
