[alsa-devel] patch_nvhdmi.c's snd_hda_preset_nvhdmi[] formatting, entry naming, new entries

Takashi Iwai tiwai at suse.de
Mon Aug 9 21:34:51 CEST 2010

At Mon, 9 Aug 2010 11:47:26 -0700,
Stephen Warren wrote:
> All,
> I'm working on a patch to add some new codec IDs to patch_nvhdmi.c. I notice
> that many lines in that table are wrapped to avoid long lines. Is there a hard
> 80 column limit for ALSA driver or kernel files? I'd find the table and diff
> much easier to read if I could simply put each new entry on a single line,
> but don't want to violate any hard-and-fast coding style rules...

The 80 column limit is no hard limit, but a very good recommendation.
Even a long table entry is often hard to read.  So, I prefer 80-chars
unless the longer line is inevitably needed.  But, it's just a matter
of taste, after all.

> Second, I wish to add entries for some GPUs that haven't yet been released.
> For these, I'd like to make the codec names simply "GPU HDMI/DP", since I
> can't expose naming for unreleased products. We'd like to get these entries
> into the driver early so that they're available in distros before products
> ship, so that the hardware "just works" out of the box. Indications so far
> are that these devices will simply be standard Azalia codecs, and hence not
> need any code/tables/quirks to operate correctly (i.e. they'll follow the
> existing "MCP89" path).

A generic name can be used there.  You can put some numbers (e.g.
vendor id hex) as a tentative id, too.

> Finally, the naming for existing discrete GPU entries (GT220/GT21x/GT240) is
> a mixture of engineering GPU names and marketing names. I'd like to edit these
> names to also be simply "GPU HDMI/DP" for consistency. Unfortunately, I'm not
> allowed to submit engineering GPU names for any GPUs, and using marketing
> names in these entries doesn't make sense, since there may be multiple
> marketing names per codec ID, and the marketing names many change over time.

Having something as an id is good in general.  So, it's nice to use
some generic names, but better to have unique string for each entry.



More information about the Alsa-devel mailing list