Re: [Tails-dev] New support page /support/known_issues/graph…

Supprimer ce message

Répondre à ce message
Auteur: sajolida
Date:  
À: The Tails public development discussion list
Sujet: Re: [Tails-dev] New support page /support/known_issues/graphics
intrigeri:
> sajolida:
>> - Shall we advertise people to try the "Troubleshooting Mode"? Does it
>> help with graphics cards?
>
> Yes, it adds "nomodeset" which is needed for some graphics cards.


Everybody agrees on that it seems :) I think we should document it as a
workaround for the cards where it makes a difference.

>> - Does it make sense to link to Redmine tickets? For example, #11095 for
>> Radeon HD was closed because we had nothing else to do but the problem
>> still exist.
>
>> Is it worth making this information visible to users?
>
> Only if the ticket is still open i.e. we think we can do something
> about it: then the user can "Watch" the ticket and learn about new
> experimental ISOs they can test etc.


If we want to only link to open tickets and not closed ones then this
information will likely get quickly outdated. I'm afraid that linking to
closed tickets (by lack of maintenance) might lead to serious confusion
as it could either mean that the problem is solved or that the problem
cannot be solved...

So I would say that the cons outweigh the pros here and I'll keep them
in an HTML comment for now.

>> - Is it worth keeping track of when each issue has been updated last?
>> Here I'm proposing to keep this information in an HTML comment.
>>
>> This is information that we can get from the Git history (I tried and
>> it takes a couple of minutes) but I thought that it might help
>> cleaning the page from now and then. I thought about doing this for
>> the other known issues pages as well.
>
> In general, and for more atomically tracked issues: yes, great idea!
>
> But in this case I'm not sure how we will able to use this info for
> the intended purpose because the granularity of our entries is
> very coarse (the fact we have updated something about a Radeon HD
> model does not teach us much about the other ones).


Ok, so I'll keep my great idea for other known issues pages but not this
one :)

>> Right now I bet that it's not the case
>> but the page will get better as people report errors.
>
> I believe our current data is not that bad because I bet it comes
> straight from the lspci output that's on top of WhisperBack reports
> and that's what we tend to copy'n'paste. But we lack IDs and anyway:
> yes, this will get better.


Ok.

>> Are their ways for Technical writers and Help desk to complete or
>> verify this information? For example, could we answer questions like:
>
>> - « How can I know the ID of "Radeon HD 8790M"? »
>
> Generally:
>
>   $ grep 8790M /usr/share/misc/pci.ids
>     6606  Mars XTX [Radeon HD 8790M]

>
> … will give you the device ID: 6606.
>
> And then open /usr/share/misc/pci.ids, search for that entry, scroll
> up to the first not-commented-out line that is:
>
> 1002 Advanced Micro Devices, Inc. [AMD/ATI]
>
> … which gives you the vendor ID.
>
> Then the ID of that device is 1002:6606.


That's what I thought, thanks for the confirmation!

I might document this in comments on this page.

>> - « What name is displayed to the users of "Radeon HD 8790M"? »
>
> Search pci.ids for something that looks like the name you know.
> In this case that would be "Mars XTX [Radeon HD 8790M]".


Ok.

>> - Is the "(rev XXX)" part of the graphics card description relevant?
>
> It's relevant: different hardware revisions of the same commercial
> name may behave differently.
>
>> If so I'll have to talk about "name, ID, and revision" instead of only
>> "name and ID".
>
> It depends of what you call the name. I think the name includes the
> revision and cards with different revisions should have different PCI
> IDs. But I'm not an expert at this and I did not check. Should I?
>
> Anyway, your question seems to be about "Mention in your email […]
> [the] name and ID of your graphics cards". In this context, I believe
> the name will include the revision (and if it does not, then I don't
> know how the user would find this info to report it to us, so well).


The output of `lspci -nn` is structured like this:

$VENDOR_NAME $PRODUCT_NAME [$VENDOR_ID:$PRODUCT_ID] (rev $REV)

So far, I've called in my documentation:

- "name" → $VENDOR_NAME $PRODUCT_NAME
- "id" → [$VENDOR_ID:$PRODUCT_ID]

The "revision" comes after the "id" in the output so I would have to
name it explicitly as it's not side-by-side with what I'm calling "name"
so far.

But I'll improve my draft and ask you to review it. It might be easier
to build a common understanding :)