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

2018-04-20 Thread sajolida
intrigeri:
> sajolida:
>> intrigeri:
>>> sajolida:
 - 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...
> 
> I'm not sure: in many cases, we simultaneously decide to drop the ball
> on fixing the hardware support issue ourselves and to document the
> known issue (and workaround if there's a known one), and then we know
> that the ticket will be closed once the known issue is documented ⇒
> the known issue should avoid linking to the ticket.
> 
> So the only situation when this info will get outdated is when we
> decide to document a known issue strictly before we drop the ball on
> tracking/fixing the actual problem ourselves, and thus track the doc
> writing and the hardware support issue on different tickets. I think
> we're doing this less and less and with my FT hat on, I plan to keep
> doing it less and less: researching graphics hardware support issues
> is a huge time sucker and most of the time we don't get anything out
> of it other than what the initial hour of research (that leads to
> documenting a workaround or the lack thereof) already gives us.

I think I got it. I checked all the tickets referenced in the page. Only
two were still open (#12482 and #15116) and it's when we need more info
and more tests. So I linked to them in the workaround sections (9ac18b19c9).

-- 
sajolida
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

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

2018-04-13 Thread intrigeri
Hi,

sajolida:
> intrigeri:
>> sajolida:
>>> - 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...

I'm not sure: in many cases, we simultaneously decide to drop the ball
on fixing the hardware support issue ourselves and to document the
known issue (and workaround if there's a known one), and then we know
that the ticket will be closed once the known issue is documented ⇒
the known issue should avoid linking to the ticket.

So the only situation when this info will get outdated is when we
decide to document a known issue strictly before we drop the ball on
tracking/fixing the actual problem ourselves, and thus track the doc
writing and the hardware support issue on different tickets. I think
we're doing this less and less and with my FT hat on, I plan to keep
doing it less and less: researching graphics hardware support issues
is a huge time sucker and most of the time we don't get anything out
of it other than what the initial hour of research (that leads to
documenting a workaround or the lack thereof) already gives us.

>>> - 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.

OK.

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

Sure!

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

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

2018-04-12 Thread sajolida
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 :)
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

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

2018-04-12 Thread sajolida
sajolida:
> emma peel:
>> sajolida:
>>>   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"? »
>>
>> I ask users many times to give me the output of lspci, and it also comes on 
>> WhisperBack
> 
> The ID (as in "[10de:0a6c]") is not given by lspci and cannot be found
> easily from WhisperBack. But intrigeri answered my question, so I'm happy :)

I created a ticket (and a branch) to add this information in WhisperBack
reports. It should make the output of the GDM debugging message and
WhisperBack reports exactly the same and help maintaining
/support/known_issues/gdm.

-- 
sajolida
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

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

2018-04-11 Thread sajolida
emma peel:
> Nice page! It makes it much more clear than now, I think.

Thanks!

> sajolida:
>> I'm sending here for review a draft of a new page of known issues only
>> for graphics cards.
>>
>> This is related to the restructuring of our support pages that we
>> proposed with Cody on https://tails.boum.org/blueprint/support_page/
>> and triggered by the new error message when GDM fails to start (#14521).
>>
>> You can see the structure here:
>>
>> https://git.tails.boum.org/tails/diff/wiki/src/support/known_issues/graphics.mdwn?h=doc/15399-gdm-debugging
>>
>> I'd like the Foundations team and Help desk to have a look and comment
>> before I start migrating all the data we currently have in
>> /support/knowns_issues.mdwn.
>>
>> For example, I'm wondering:
>>
>> - Shall we advertise people to try the "Troubleshooting Mode"? Does it
>>   help with graphics cards?
>
> It helps to boot on some cards when the driver is not working. But those users
> maybe can use a specific boot option to solve their hardware support problem.

Then I think that we should recommend using the "Troubleshooting Mode"
as a workaround for the graphics cards for which 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?
>
> Yes, hopefully we could fix old issues maybe, or close them as resolved.

I'll answer to this one on intrigeri's email.

>>   Is it helpful to keep it hidden in an HTML comment like I did?
> 
> I didn't saw that.

Search for "#12482" on
https://git.tails.boum.org/tails/tree/wiki/src/support/known_issues/graphics.mdwn?h=doc/15399-gdm-debugging.

>> - 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 would be a great information to have. Sometimes I look at the Tails
> version on the issue to have a similar information. 

I'll answer to this one on intrigeri's email.

>>   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.
>>
>> - It would be good to have names and IDs of graphics cards exactly as
>>   they are displayed to people. Right now I bet that it's not the case
>>   but the page will get better as people report errors.
>
> Yes. I agree.

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"? »
>
> I ask users many times to give me the output of lspci, and it also comes on 
> WhisperBack

The ID (as in "[10de:0a6c]") is not given by lspci and cannot be found
easily from WhisperBack. But intrigeri answered my question, so I'm happy :)

>>   - « What name is displayed to the users of "Radeon HD 8790M"? »
>
> I look this up on the Internet but sometimes it is difficult, specially when 
> users
> tell you a 'laptop model' with several probable graphic cards.

I think we should use the exact name as reported from lspci in WhisperBack.

> Are you sure it is said 'graphics card'? I always thought it was 'graphic 
> card'/'graphic cards'.

https://en.wikipedia.org/wiki/Graphics_card
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

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

2018-03-22 Thread intrigeri
hi,

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.

> - 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.

>   Is it helpful to keep it hidden in an HTML comment like I did?

Yes.

> - 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).

> - It would be good to have names and IDs of graphics cards exactly as
>   they are displayed to people.

Yes! As one of the main persons who updates this info I'll keep it in
mind.

>   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.

>   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.

>   - « 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]".

> - 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).

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.