Re: [GNU-linux-libre] Nouveau: NONFSDG listing and current status?

[Rubén Rodríguez]

> On 05/17/2011 04:44 PM, Rubén Rodríguez wrote:
> >> Right now a nouveau-kernel-source package is listed on the NONFSDG
> >> page (http://libreplanet.org/wiki/NONFSDG#nouveau-kernel-source). 
> > 
> > That entry relates to karmic and jaunty, which both reached end of
> > life.
> 
> Well, that might be confusing point #1.  :)  Put that way, it's not
> immediately obvious to me whether this means "The blobs were in the
> upstream source as of karmic's release, but gone by lucid's," or
> whether it means the blobs were specifically added in Ubuntu (less
> likely, but still possible).

It is not an Ubuntu related problem. The first kernels after nouveau's
inclusion on the main tree had a blob, which later was removed when
they figured out how to generate the code at runtime. Since Ubuntu uses
a fixed kernel version for every release, only jaunty and karmic were
affected.

> > The current nouveau implementation in most distros is blob-free,
> > although it seems to be some new (optional, IIRC) blobs in the
> > latest kernels, so partial deblobbing may be necessary again in the
> > future.
> 
> That generally sounds like good news, thanks.  Is there a Nouveau
> version number or something like that that made the whole thing
> nonfree?

I have no idea, I just look into the linux-libre deblobber for every
kernel version I use to see if it comes with a nouveau part or not.

> If so, I think it would be most helpful to list Nouveau
> generally in NONFSDG, with a note that the problem was resolved as of
> version X -- that's a pretty common situation on the list at this
> point.

Well, since the problematic part of nouveau is the kernel module I think
it would make more sense to document it elsewere, as the list is for
packages. But not all the distros listed as free are using linux-libre,
so it would make sense to make this kind of problem more visible.

> > About the other free drivers, I've been looking into the Radeon
> > blobs, and in most cases they are simple 2kb -with some padding
> > zeroes- register dumps for a state machine initialization. If
> > someone more skilled than me could break them into something
> > documented we could have a lot more cards supported.
> 
> If we know for *sure* that they're just initialization values

Well, that's what AMD's John Bridgman told me, more exactly:
"They are state tables for hardware state machines.". When I asked for
some documentation, he refused replying that "we are talking about
horizontal microcode for hardware state machines so we would need to
expose the internal design of our most complex hardware blocks."

> Initialization values aren't code as such and so they don't seem
> problematic to me personally (although I wouldn't mind getting a
> second opinion on that).

I would need it. This numbers are required to enable 2D/3D acceleration
as well as managing DRM (the bad kind, as in hdmi connection quality
limitations and such), so I think having some basic documentation on the
data sections and their purpose is a must.

The thing is, I feel like we lack that doc just because nobody tried. :/