It’s caturday, apparently.

(Not shown: a link about cats further down the page.)

The longer it takes to fix a bug, the smaller the fix will be.

When I first read this little gem of wisdom on DadHacker, I literally laughed out loud.  It was the same month that we finally resolved the once-infamous fd.o bug #13405.

#13405 was filed against xf86-video-radeonhd towards the end of November, 2007.  xf86-video-ati has a counterpart as bug #19215, but filed almost a year later.   Despite a handful of very bright core developers and a few dedicated newbies (including yours truly) looking very closely at the problem, the fix was not to be committed until early May of 2009.

That’s over seventeen months.

To be fair, I don’t think there were any serious attempts at actually resolving the bug until I came along a year after its initial filing, eager to prove to the open source world that I have what it takes.  Even accounting for that, however, this was a process that took roughly five months.

In that time, a couple other commits fixing cursor corruption were made, but they turned out to be additional bugs that were only affecting certain hardware.  While both happened under equally peculiar circumstances, the original bug remained unresolved, despite multiple pairs of eyes and man hour investment in the double digits.

Finally, in the first week of May, 2009, the ever-awesome Alex Deucher made commit da58e351 to xf86-video-ati, which I promptly ported to radeonhd, finally closing a year-and-a-half old bug.

So, what was the problem that plagued us for so long?

-	RHDRegWrite(Cursor, Cursor->RegOffset + D1CUR_CONTROL, 0);
+	RHDRegWrite(Cursor, Cursor->RegOffset + D1CUR_CONTROL, 0x00000200);

One bit.

Laugh out loud, indeed.

I believe it to be a totally awesome and worthwhile goal.

One of the most prominent parts of my software development history is my involvement with Sharune.  Today, while attempting—and so far failing—to locate some old Delphi code written for this little MUD, I decided to do a search for the thing that I had built to see if it had become yet another artifact of the web.

No such luck.

What I did find, however, was this old forum thread of me seeking help with what was the precursor to that project.

This, essentially, is the moment I stopped being just a video game nerd and started becoming a “fucking prolific” hacker.

It’s also a huge asshat.

The three fish are housed in a pathetically (but not quite unethically) small aquarium, and have only each other for amusement.  Now, I don’t know what goldfish or carps usually do for amusement when not being fed, but I’ve often noticed the largest of the three using the others to play what I’ve dubbed Upside-Down Fish.  The rules are simple: pick a fishmate, chase it into a corner, use the aquarium wall to flip your mate over and push it to the surface, then see how long you can keep it upside-down.

Remember those old-timey cartoons where sometimes a bully would pick up a smaller guy, roll him into a ball, then use him to play hoops or knock down some pins?  It’s exactly like that.  Except it’s only slightly funny, and mostly just mean.

In the words of the wise animal sanctuary warden:

Well, animals are not like people, Mrs. Simpson. Some of them act badly because they’ve had a hard life, or have been mistreated…but, like people, some of them are just jerks.

It’s this last point that I would like to elaborate on: why is there such an asymmetry of expectations for job seekers when compared to those in positions to hire?

(Of course, there is a clear difference in the volume of applications an employer may receive and how many simultaneous application processes an employee-hopeful is going through at the moment.  Let’s assume that the in-person interview has happened, and there is no expectation of a follow-up interview.)

Through the various career preparation courses and workshops I have had to endure, there was a consistent message that I, as a job seeker, should do my best to research and learn more about the potential employer and the position in question before sitting down at the interview.  However, in most cases, the true nature of a position is not revealed until the interview is happening, and, all things considered, this is reasonable.  What isn’t reasonable is the fact that employers are not held up to the same expectations.

Truth be told, half the time, I am unconvinced my interviewer has even read my relatively short, 1.2 page resumé beyond scanning the headers.  I am, however, fairly convinced that none have taken the time actually investigate my open source work.  Some don’t even seem to understand that I had just finished school, and unlikely to have years of professional experience.

However, this is a minor annoyance compared to the lack of communication following an interview.  Despite the promises of “get back to you next week” and “staying in touch”, only some ever do.   I am not expecting feedback on my interview performance or tips on how to do better next time; a courtesy one-liner will suffice. Paradoxically, but not surprisingly, the probability of being notified of a rejection seem to be inversely proportional to the size of the company in question.  Empirically, I have had exactly zero rejection messages from companies big enough to have dedicated HR staff.  Most of the smaller programming shops have been good in this respect, but the score is not quite perfect.

Granted, I have not requested for a response when none were received in the assured time frame.  And, frankly, why should I?  If I were responsible for making the final decision on a business transaction of such a scale, I will have the common courtesy to notify the other parties affected regardless of outcome.  However, as a job seeker, the expectation of such a reciprocation is apparently foolish.

The mind boggles.

I will end with this list of wishes and advice for employers:

• If you are collecting resumes over a month or more, and plan to have phone screenings, don’t leave it all until after the deadline.  We might not remember having applied with you at all.
• If you have brought in candidates in for face-to-face interviews with the expectation that the outcome is Hire or No Hire, do let them know regardless of the outcome.  You wouldn’t leave a business partner hanging like that, would you?
• Don’t take weeks making the final decision after the interviews are held.  In the odd chance there is a good reason, let people know.
• Research us.  If we have impressive stuff to show, we would, and it’s not always the case that it should belong on a resumé.
• Treat this with the same professionalism as you would any other business relationship.

X11R7.5 released – but what is it?

The short answer: never; 3D acceleration is the domain of Mesa.

But, of course, it’s not as simple as that.  For the long answer, read on…

More than Meets the Eye

Your Linux “video card driver” is not a single blob of code.  As with any sufficiently large piece of software, things need to be broken up into discrete components for both technical and maintainability reasons.  And, there is no doubt a complete graphics stack is large: the AMD Catalyst driver is a 93MB download.  That’s over one hundred Mega bytes of executable code and supporting data.  In that humongous pile of bytes are roughly half a dozen different components working together to deliver your polygonal needs, without counting the configuration tools.  This, unfortunately, is not common knowledge.

In the open source world, our drivers are much more svelte, partly because less features are supported, and also because application-specific optimizations are omitted.  Unlike the proprietary drivers, however, the boundaries of separation are clearly visible.  In respect to “driver” code that is specific to a particular hardware, there are, more or less, three separate components involved:

• X display driver
• Mesa DRI driver
• Kernel DRM driver

Indeed, in true UNIX fashion, all of these are actually worked on as completely separate projects, albeit with significant overlap in the personnels involved. (Proprietary drivers from AMD and nVidia provide equivalents to all three in a single package.)

DDX: People’s Favourite Barking Tree

When the words “Linux video card driver” are invoked, the DDX is what people typically think of.  And, for good reason: historically, when configuring X11, the DDX was one of the few things that had to be configured by the user, and could be selected. This is your radeonhd, radeon, nv, and intel.

The main function of these drivers is to provide mode setting: that is, selecting the screen resolution, colour depth, turning outputs on and off, etc. The X server uses the DDX to perform basic, essential hardware manipulation so that you can have a graphical display at all.  Each DDX is hardware-specific: indeed, it stands for Device Dependent X (but this trivia is not very important.)

That’s not all.

A DDX also provides hooks that allow the X server to offload certain drawing operations to the GPU so that they can be accelerated.  XAA, EXA, and UXA all fall under the DDX’s domain, in addition to Xv.  The former group is responsible for things like moving windows around your desktop, scrolling a website in your favourite browser, and compositing desktop effects.  The latter handles video rendering.

To summarize, everything 2D is the domain of the DDX.  And, in simple terms, it is its only domain.  If you are looking for 3D acceleration, this is not the tree to be barking up at.

Mesa DRI Driver: The Invisible Hero

OpenGL is the method with which applications achieve 3D rendering under Linux.  Unfortunately, but for good reasons, it is not possible to go from an OpenGL function call to manipulating hardware states in a single step.  Multiple translations must be done under the hood to convert those calls into something that the GPU can understand.

Mesa is largely divided into two parts: an OpenGL compatible library stack that applications can call into, and DRI drivers that translate Mesa-internal instructions into forms that the video hardware can understand and execute.

After a call is made to the Mesa library and it has been translated into a GPU-specific language, the resulting operations need to be sent to the hardware for execution.  Mesa, however, cannot do this without help as it lives in user space:  only kernel space code is allowed to touch hardware directly.  Note that DDX is one of very few exceptions to this rule: it is technically user space code but allowed direct hardware access, for better or worse.

Unfortunately, sending these instructions through the DDX, and hence X, is not fast enough.  This point finally brings us to…

DRM: Bridge to the Hardware

The final piece of the driver stack is the Direct Rendering Manager.  Oversimplified, it exposes certain features of the hardware with an abstraction layer to user space such that applications like Mesa can make use of a GPU more efficiently.

It is also the job of the DRM layer to provide measures that ensure multiple applications that require working closely with the hardware to not step on each other’s toes.

DRM drivers are Linux kernel modules, which are accessed by user space through libdrm.

All Together Now

So, say you have a shiny new RadeonHD 4870.  What driver features would it take to have it “working under Linux”?

First of all, you need a DDX that can properly mode set the GPU. radeonhd and radeon have both been capable of this for some time.

For fast 2D, again, support needs to be added to the appropriate DDX.  Mostly done, as above.

In terms of accelerated 3D, support from both Mesa and the kernel are required.  As of this writing, work on both are progressing nicely but remain in experimental states.  And, in this particular case, changes were required to libdrm as well.

It should now be clear that, for newer video hardware, there is rarely a trivial answer to the question “Does it work in Linux?”  In fact, it can be downright confusing.

Now, Lets Make It Complicated

Video hardware rarely change completely from generation to generation.  This means that the same code is often times used to operate GPUs from multiple generations.  Understanding which version of which component you need can occasionally become a messy affair.

To draw an example from the Radeon world, R3xx (Radeon 9xxx) and R5xx (Radeon X1xxx) GPUs share a similar 3D engine, but the mode setting engines are drastically different.  Therefore, while you can use the same Mesa DRI driver on both (r300_dri.so), radeonhd will not work on the former.  As for DRM, radeon (note that there is a kernel module and a DDX bearing this name) takes care of everything. (There are, of course, oddities from those generations that do not fit in to this generalization.)

Furthermore, there is currently a push in Linux to move video mode setting into the kernel (Intel is already there).  Kernel Mode Setting, more commonly referred to as KMS, brings the user- and kernel-space separation back to X, relieving the responsibility of hardware manipulation from the DDXes and putting it solely in the DRM drivers.  The details of this topic will—perhaps—be explored another time.

So, Now You Know

Armed with this knowledge, your task is to now educate your fellow Linux users regarding the mistaken concept of “The Linux Graphics Driver”.  Your efforts will, hopefully, help reduce the need for developers to repeat this explanation, again and again.