Help needed: clean up and submit KMS driver for Geode LX to LKML

Ever since X.org switched to rootless operation, the days of the Geode X.org driver have been numbered. The old codebase dates back from Geode's early days at Cyrix, was then updated by NSC to add support for their new GX2 architecture, from which AMD dropped GX1 support and added support for their new LX architecture. To put it mildly, that codebase is a serious mess.

However, at least the LX code comes with plenty of niceties, such as being able to detect when it runs on an OLPC XO-1 and to probe DCC pins to determine the optimal display resolution on other hardware. This still doesn't make the codebase cruft-free.

Anyhow, most Linux distributions have dropped support for anything older than i686 with PAE, which essentially means that the GX2 code is just for show. Debian is one of very few distributions whose x86-32 port still ships with i686 without PAE. In fact, the lowest common denominator kernel on i386 is configured for Geode (LX).

A while back, someone had started working on a KMS driver for the Geode LX. Through word of mouth, I got my hands on a copy of their Git tree. The driver worked reasonably well, but the codebase needs some polishing before it could be included in the Linux kernel tree.

Hence this call for help:

Is there anyone with good experience of the LKML coding standards who would be willing to clean up the driver's code and submit the patch to the LKML?

xf86-video-geode 2.11.18

Yesterday, I pushed out version 2.11.18 of the Geode X.Org driver. This is the driver used by the OLPC XO-1 and by a plethora of low-power desktops, micro notebooks and thin clients. This release mostly includes maintenance fixes of all sorts. Of noticeable interest is a fix for the long-standing issue that switching between X and a VT would result in a blank screen (this should probably be cherry-picked for distributions running earlier releases of this driver). Many thanks to Connor Behan for the fix!

Unfortunately, this driver still doesn't work with GNOME. On my testing host, launching GDM produces a blank screen. 'ps' and other tools show that GDM is running but there's no screen content; the screen remains pitch black. This issue doesn't happen with other display managers e.g. LightDM. Bug reports have been filed, additional information was provided, but the issue still hasn't been resolved.

Additionally, X server flat out crashes on Geode hosts running Linux kernels 4.2 or newer. 'xkbcomp' repeatedly fails to launch and X exits with a fatal error. Bug reports have been filed, but not reacted to. However, interestingly enough, X launches fine if my testing host is booted with earliers kernels, which might suggest what the actual cause of this particular bug might be:

Since kernel 4.2 entered Debian, the base level i386 kernel on Debian is now compiled for i686 (without PAE). Until now, the base level was i586. This essentially makes it pointless to build the Geode driver with GX2 support. It also means that older GX1 hardware won't be able to run Debian either, starting with the next stable release.

xf86-video-geode: Last call, dernier sévice

I guess that the time has finally come to admit that, as far as upstream development is concerned, the Geode X.Org driver is reaching retirement age:

While there have indeed been recent contributions by a number of developers to keep it compilable against recent X releases, the Geode driver has accumulated too much cruft from the Cyrix and NSC days, and it hasn't seen any active contribution from AMD in a long time. Besides, nowadays, Xserver pretty much assumes that its runs on an X driver that leverages its matching kernel driver and thus won't require root priviledges to launch. This isn't the case with the Geode driver, since it directly probes FBDEV and MSR, both of which reside in /dev and require root priviledges to access.

On Debian, as a stopgap measure, the package now Recommends a legacy wrapper that enforces operation as root. Meanwhile, other distributions are mercilessly droping all X drivers that don't leverage KMS. Basically, unless a miracle happens really quick, Geode will soon become unusable on X.

Back when AMD was still involved, a concensus had been reached that, since the Geode series doesn't offer any sort of advanced graphic capabilities, the most sensible option would indeed be to make a KMS driver and let Xserver use its generic modeline driver on top of that, then drop the Geode X driver entirely. Amazingly enough, someone did start working on a KMS driver for Geode LX, but it never made it as far as the Linux kernel tree (additionally, Gitorious seems to be down, but I have a copy of the driver's Git tree on hand, if anyone is interested). While I'll still be accepting and merging patches to the Geode X driver, our best long-term option would be to finalize the KMS driver and have it merged into Linux ASAP.

xf86-video-geode 2.11.17

This morning, I pushed out version 2.11.17 of the Geode X.Org driver. This is the driver used by the OLPC XO-1 and by a plethora of low-power desktops, micro notebooks and thin clients. This is a minor release. It merges conditional support for the OpenBSD MSR device (Marc Ballmer, Matthieu Herrb), fixes a condition that prevents compiling on some embedded platforms (Brian A. Lloyd) and upgrades the code for X server 1.17 compatibility (Maarten Lankhorst).

Pending issues:

• toggle COM2 into DDC probing mode during driver initialization
• reset the DAC chip when exiting X and returning to vcons
• fix a rendering corner case with Libre Office

GNOME is destroying the whole GTK universe

When GNOME 3.14 components were uploaded into Debian (just a few days before the Jessie freeze started), GNOME stopped working on two video platforms: Geode (xf86-video-geode) and NVIDIA (xf86-video-nouveau). On Geode, GDM launches into a black screen. On NVIDIA, GDM launches as expected, but then the GNOME session itself barfs with the dreaded "Oh No! Something went wrong. [Logout]" dialog during session initialization. Basically, components in GNOME have become too tightly dependent upon some video driver features. Thinking out loud, I figured that reverting to a desktop environment that is based upon GTK+3, without GNOME's bells and whistles, would at least restore operation on my NVDIA hosts. Alas, it does not: Cinnamon, too, barfs during session initialization. Great. Now what?

xf86-video-geode 2.11.14

A few days ago, I pushed out version 2.11.14 of the Geode X.org driver. This is the driver used by the OLPC XO-1 and by a plethora of low-power desktops, micro notebooks and thin clients.

This release mostly features long-overdue fixes to rendering issues under GTK3+ and xulrunner, plus yet more ongoing changes to make this driver compile under recent X servers.

Sadly, the release took place much too late to be included into the upcoming stable Debian version, Wheezy, which is already deeply into freeze, pending publication.

xf86-video-geode 2.11.13

A few days ago, I pushed out version 2.11.13 of the Geode X driver. This is the driver used by the OLPC XO-1, by a plethora of thin clients such as the ThinCan, by low-power desktops such as the Linutop and by a few notebooks such as the eCafé EC800.

While this release indeed features a few bugfixes (mainly to keep this driver compilable on the latest X server), the lion's share of the changes involve a complete overhaul of the build scripts, courtesy of Gaetan Nadon. The key motivation for this overhaul was to acknowledge the efforts made by third-party contributors to make the driver compile on BSD variants. Sure enough, this release finally compiles on FreeBSD and, low and behold, on Hurd.

However, the hybrid nature of Debian's FreeBSD kernel-based GNU operating system variant posed an additional challenge, because it provides usable support for Video for Linux version 2 (V4L2), but without the full complement of Linux definitions. This resulted in one post-release commit (included in Debian and Ubuntu package 2.11.13-2), following which my assertion that we could now safely define this package as Architecture: any-i386 finally proved to be a safe one for Debian-based operating systems.

At this point, I'm curious as to how many more operating systems, especialy BSD variants, can finally use this driver. Patches to further improve support of non-Linux systems are welcome.

X.org video driver Geode 2.11.12

Today we published version 2.11.12 of the X.org Geode driver, code-named "Squeezing the Wheezy out of Debian" in honor of the recent Debian stable release. 2.11.12 is yet another minor bug-fixing release, this time featuring yet another EXA fix for the LX component, courtesy of the OLPC team, plus the removal of an obsolete V4L1 include that was preventing the building of the ztv video input component of our driver since Linux kernel 2.6.38 - thanks to the Fedora and Ubuntu teams for spotting this!

X.org video driver Geode 2.11.9

Released just a few hours ago:

We are pleased to announce this maintenance release of xf86-video-geode. It features a plethora of bug fixes, a few documentation updates and one performance enhancement. This release also marks the return of Advanced Micro Devices to the development team. Please read the content of NEWS for more details.

In practice, this Geode 2.11.9 release mostly fixes the growing number of rendering issues that were exposed with each successive release of the X.org server core. Among other things, it restores the ability to correctly view video streams on Totem and other media players, it fixes icon rendering bugs that affected various desktop environments and web browsers, it removes all remaining compiler warnings and, as a byproduct of fixing one rendering issue, the speed of our driver improved dramatically.

This is one release that will definitely please users of the OLPC XO-1 and of thin client hardware running on LTSP!

Hell just froze over a.k.a. Squeeze is frozen

Just noticed about an hour ago on debian-announce: Squeeze entered into freeze tonight. Hurray! What this means in practice is that, unless a new version of something fixes a serious bug, it will not be allowed to trickle down from Sid into Squeeze on time for the actual release.

Still, I cannot help but feel sad that it happened just a few days short of upstream releasing the Geode 2.11.9 driver for X.org, because AMD recently committed a lot of resources towards fixing all outstanding issues on this driver and yet one major Linux distribution is about to release without those fixes, unless the Release Manager agrees to let us squeeze 2.11.9 into, well, Squeeze. Doable? Possibly, if enough people calmly ask the Release Manager for it.

xf86-video-geode: new contributors shake off the dust

A couple of years ago, the Geode X.org driver lost its main contributor, due to random attrition at AMD after the company experienced severe losses at the end of a quarter. Since then, yours truly and a few random contributors have been trying to keep this driver at least remotely usable, with mixed results.

Over the past few weeks, the driver has seen new contributions, thanks to the addition of two engineers from AMD Taiwan who have been going through the list of outstanding bugs and learning the ropes of collaborating with the Free Software community. This, in turn, had a snowball effect and motivated old contributors from the OLPC project and from the thin client community to return to the driver. Hurray!

Let's give a warm welcome to Frank Huang and Hunk Cui from AMD and, if you notice any issue with the driver that is not already reported, please file a report to help us become aware it.

Cheers!

xf86-video-geode: EXA Composite support broken on X server 1.7

Just a quick note to everyone who recently upgraded their X server to 1.7 on Geode hardware to report that changes in X server since 1.6 have exposed and escalated bugs in our Geode driver that make EXA Compositing fail, resulting in broken image support on GTK2+ applications. As a temporary work-around, add this line to /etc/X11/xorg.conf in the Devices section:

Option "EXANoComposite" "true"

On my Lucid host, this gives me the following minimalistic xorg.conf:

Section "Device"
 Identifier "Geode Video"
 Driver "geode"
 Option "EXANoComposite" "true"
EndSection

We're currently working to produce new upstream packages that default to EXANoComposite as a temporary work-around, so that the driver at least produces useful results by default, and push this to distributions ASAP, especially keeping in mind pending Squeeze and Lucid releases.

Meanwhile, AMD recently assigned new engineers to contribute to the driver's development and to eventually pick up maintenance, so we should soon have a permanent solution to these recent breakages in acceleration support for both GX2 and LX chipsets.

Help Wanted: testers for the Geode X.org driver on GX2 "Red Cloud"

A number of small fixes have been committed to the upstream X.org GIT to improve support for the "Red Cloud" Geode variant (called GX2 for late NSC chips and GX for newer rebranded AMD chips) and we desperately need volunteers to test those changes, before we release a new upstream tarball. If you have some Red Cloud hardware on hand and at least basic knowledge of how to compile software on Linux distributions, please contact me to the e-mail address listed in the ChangeLog. Thanks!

PS: if you're on Ubuntu, test packages are available for Lucid via my PPA.

wanted: 'lspci -vvv' output for Geode SC1100, SC1200, SC1400

As I'm trying to better document which Geode models bear which PCI vendor and device ID, I'd need volunteers to e-mail me the output of 'lspci -vvv' for their Geode SC1100, SC1200, SC1400 -based hardware. Please send the result to my iki.fi address. Thanks!

PS: the part that interests me is the PCI ID of all Geode CPU and Companion Chips shown by 'lspci'. This requires setting several additional levels of verbosity, because this information is hidden from the normal 'lspci' output.

wanted: Geode "Red Cloud" GX2 hardware

Ever since X server 1.5 was released, various regressions started affecting our GX2 code in xf86-video-geode. We couldn't figure out what went wrong since our GX2 code hadn't changed in ages and we couldn't think of any ABI or API migration that would cause these regressions.

Well, it turns out that someone had quietly rewritten part of the X server core, which broken things from under our feet.

In the end, the change required to restore operation was minimal, but it nonetheless caused problems for several thin client users who complained loudly while the xf86-video-geode team scratched their head wondering what went wrong.

Still, it essentially meant that GX2 users suffered through Intrepid and Jaunty without a solution in sight, which is of course unacceptable. I'm also aware of at least one startup who lost a fairly lucrative LTSP maintenance contract, simply because their customer's GX2-based thin clients could not be made to work on Ubuntu since Hardy. Ouch!

In order to prevent this from ever happening again and to ensure that regressions get noticed before they reach critical mass, I'd like to solicit a hardware donation: something GX2-based with a small hard-disk or CompactFlash socket and 100baseT Ethernet.

My contact info can be found on my homepage. Please make sure that you contact me upfront to agree on the delivery method, before sending me any hardware.

Thanks!

xf86-video-geode 2.11.4 - the GX2 edition - almost done

Over the last few days, several improvements in the documentation and some fixes for GX2 issues were committed to the Geode X.org driver, in addition to routine cleanups in the standard includes and build macros. Integration of GX1 support still hasn't started.

We're especially interested in getting feedback from GX2 users as to whether this release restores basic operation for them or not. We published test packages for Ubuntu/Jaunty at:

https://launchpad.net/~q-funk/+archive/ppa

If we haven't heard anything by Friday, we'll release this as xf86-video-geode 2.11.4 as-is.

xf86-video-geode 2.11.3

A few days ago, we released version 2.11.3 of the Geode X.org driver. As you'll notice from the version number, this is only a maintenance release, mainly to fix crasher bugs that appeared since X.org server core 1.6 was released.

Meanwhile, Otavio Salvador has been busy cleaning up our GX2 support and, in the process, he also found a few interesting regressions that affect LX support as well.

Unfortunately, our goal to integrate GX1 support into our unified Geode driver still hasn't been reached, due to a lack of resources: most people who knew anything about GX1 and SC Geodes and who had access to development hardware have moved on. As such, help to complete this goal is extremely welcome.

Geode X.org driver fix for GX2/CS5535 released

After a rather hectic holiday season, I returned momentarily to pending Geode X.org driver issues. The current status:

• On Debian, 2.10.1 is in Testing and Unstable, while 2.11.0 is in Experimental. For those who need 2.11.0 right away, the experimental package builds as-is using Lenny dependencies. For everyone else, I'll probably get around producing a proper backport once Lenny is released.
• On Ubuntu, 2.9.0-1ubuntu2.5 just entered Hardy-updates with cherry-picked fixes for DCC support on GX2/CS5535 hardware. Meanwhile, Intrepid has 2.10.1 and Jaunty has 2.11.0, with a backport of the later having been requested for Hardy-backports.

I'm especially interested in hearing from users of GX2/CS5535 hardware to see if these recent uploads finally fixed DDC probing for them or not. Just respond to relevant existing bugs or, if necessary, open new bugs to report any regression.

xf86-video-geode 2.11.0: last call!

With yesterday's release of version 2.11.0 of the X.org driver for the Geode GX2/LX, a whole cycle was wrapped up for many of the developers involved:

• Jordan Crouse was among the unlucky ones who recently lost their job at AMD. The same layoff also affected Coreboot developer Marc Jones and other Geode specialists (see Jordan's blog article for details).
• Several members of the OLPC project are also moving on, now that most Linux kernel and X.org patches have been merged upstream.
• People like myself who were working in the thin client industry on Geode-based products are also moving on.

As such, remaining bugs and our milestone goal to merge back support for older GX1 Geodes might never be taken care of. From this perspective, we welcome active participation of new developers with access to a wide variety of Geode hardware to contribute and, eventually, take over upstream maintenance of xf86-video-geode.

Available for a new job

A couple of years ago, I started what has probably been the best job I've held so far, as a Business Development Manager for Artec Group where I focused on marketing and selling the ThinCan LTSP client.

During that time, I used a combination of Guerrilla Marketing techniques to spread the word about this cool Estonian embedded platform in its LTSP client configuration and defined an extremely tight market-oriented focus that saw this relatively obscure electronic design start-up rise to the forefront of the LTSP hardware market and also brought the company commendable notoriety in the Coreboot community, thanks to its Programmable LPC Dongle, a low-cost ROM emulator that can be used to bootstrap various embedded hardware and test firmware images.

Looking back at close to 3 years with Artec (if we include the stint I did at Linutop), I most fondly remember how I managed to bring the Estonian and Turkish nations closer together in collaborating on Innovation. On my first visit to Turkey, I had noticed that very little is know about Estonia in Turkey, even though both countries have a collaboration that dates back to the 1920's, so my tactic was to introduce Estonia's achievements as a whole, to establish confidence in Artec's offering. It worked:

Among other things, my idea to organize an Estonian ICT Conference during the visit of Estonian PM Andrus Ansip in Turkey created a lot of extremely positive buzz that resulted in Estonia being mentioned as a trendy country in a prime time Turkish TV series. During this time, I've also made a lot of contacts among the Estonian and Turkish business communities and, more surprisingly, among the Estonian diplomacy who, much to my amazement, welcomed my ideas for better promoting Estonian interests abroad with great enthusiasm.

Come December 2008, my time at Artec will become a page in my employment history. While the Thincan remains one of Artec's key products, current marketing and sales resources are focused on new markets and new technologies that completely fall outside my core expertise, which is why the company decided to let me go.

I thus welcome offers from interested parties in Coreboot or LTSP markets. Other refreshing offers from outside the box - such as in business diplomacy - are equally welcome, as I've been pondering a career change for a long time.