-----Original Message----- From: Tiago Vignatti <[email protected]> Sent: Wednesday, July 14, 2010 11:03 AM To: ext Timothy Meade <[email protected]> Cc: Mikhail Gusarov <[email protected]>; [email protected] <[email protected]> Subject: Re: [PATCH] Remove xcalibrate and tslib support
Hi Timothy! Sorry to reply this thread so late. On Thu, Jul 08, 2010 at 08:34:20PM +0200, ext Timothy Meade wrote: > > I would rather move > forward not backwards and getting XF86 to a usable memory footprint > and startup time would certainly be moving forward (unacceptible > startup time being any noticable delay between starting /usr/bin/X and > completing vt switch). I have a very vague initial proposal for > replacing kdrive ddx with a more modular and XF86 compatible > replacement and am also researching optimization options for XF86, > simplifiying probing and replacing with bus enumeration and maybe > flattened device trees which Ubuntu/Linaro have shown interest in. nice! I kinda started to record some memory usage of Xorg and Xfbdev (with some help of Ajax and Mikhail). You may find this interesting and would be nice if you could run mem-usage script on your device to improve this info: http://people.freedesktop.org/~vignatti/scrutinizing-x-mem/standalone-usage/ http://people.freedesktop.org/~vignatti/scrutinizing-x-mem/standalone-usage/xorg_2010-07-14_1.8.0RC1_mydevice.txt http://people.freedesktop.org/~vignatti/scrutinizing-x-mem/standalone-usage/xfbdev_2010-03-25_dottedmag.txt This second link shows a device running with ~ 4.5MB of RSS. This is with Xorg 1.8. On the third link you can see that Mikhail got ~ 3.9MB of RSS using kdrive Xfbdev. That's not much difference when comparing with Xorg. Xorg 1.9 will be bringing a bit more expertise regarding memory usage and we're going to be able to disable other components that for instance I don't care for my device (such as DBE, Xdmcp, libpciaccess). So, as Ajax stated, it's very likely that we'll be able to delete kdrive hardware servers if memory is the only advantage on those (and honestly I get always shocked when someone comes to this mailing list mentioning that still using kdrive. Move on :) Cheers, Tiago -- Cool. I'm not testing on the device directly but I'll look into getting a qemu 'equivalent'. Yeah, we had a couple of issues that led to using Xfbdev when we started this over a year ago with the HTC Kaiser. Mostly that the kernel trees we were working for were designed for Android and the graphics hardware is very weird, requiring a refresh operation to actually draw anything which has to be done manually. We also needed tslib and the only way we could see to get that working was Xfbdev. The other issue is how Xorg sets video modes even on fixed fbdev which was due to the clock rate or something like that being 0 and X not liking it. When I've said that Xorg was slow initializing on our hardware I simply mean there's a visible delay before switching to the thatch scrren (stipple?). We did not see this same thing with kdrive and I began investigating why in the course of trying to get tslib working. I'm perfectly happy to swtich to the XF86 ddx if it can meet a few basic requirements. There seems to be no reason to fully probe video modes on a fixed TFT connected to a LCDC. We have no need to parse xorg.conf, but that might be trivial with the hotplug improvements though we need to be able to match what hardware is actually in use by sysfs identifiers so the same image can be used on multiple devices. Memory usage is getting to be less of an issue, but we have to remember this isn't just X, it's X plus an phone ui and window manager of some description. I would say if it works on freerunner it's a non issue and all of the hardware we are targetting now has significantly more ram than that. I'm still interested in building a next generation of kdrive on a Xephyr like base and abstracting the fb for use cases that are only now starting to be explored. I'm also interested in using a kbuild like config file allowing for components of the X server to be built in for devices with slow flash memory that don't have enough ram to cache everything (xip like). I think a multi hardware kdrive could work in this fashion while also working as Xvfb and allowing for a more advanced device independent implementation of shadowfb, rotation, xrandr1.2 and pluggable heads (mobile HDMI for instance) as well as KMS and DRI2 on mobile gpus (expanding on Weiss and Code Aurora's work). I'm curious as to Nokia's roadmap in this area and how MeeGo fits in. Thank you, Timothy Meade -- tmzt #htc-linux _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
