[PATCH] Remove xcalibrate and tslib support

[Tim HRM]

-----Original Message-----
From: Tiago Vignatti <tiago.vignatti at nokia.com>
Sent: Wednesday, July 14, 2010 11:03 AM
To: ext Timothy Meade <zt.tmzt at gmail.com>
Cc: Mikhail Gusarov <dottedmag at dottedmag.net>; xorg-devel at lists.x.org
<xorg-devel at lists.x.org>
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