brainstorming for UDS-N - Hardware Compatibility

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

brainstorming for UDS-N - Hardware Compatibility

Allison Randal-4
The Hardware Compatibility track is about supporting the widest possible
selection of hardware, in an easy-to-use fashion (GUI tools, avoiding
manual configuration, etc), with sane default settings.

What's high on your list for this area?
Allison

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: brainstorming for UDS-N - Hardware Compatibility

Scott Kitterman-3
On Tuesday, September 28, 2010 03:33:29 pm Allison Randal wrote:
> The Hardware Compatibility track is about supporting the widest possible
> selection of hardware, in an easy-to-use fashion (GUI tools, avoiding
> manual configuration, etc), with sane default settings.
>
> What's high on your list for this area?
> Allison

I can now, if I just know to run Jockey, get wireless networking in a live
session with restricted drivers.  We have a question for installing restricted
drivers during install, but no prompt to the user during the live session
(it's possible this limitation only applies to the KDE installer, I didn't try
it in Gnome).  Since the installation experience is now significantly enhanced
if done with an active internet connection, I would like to see us push to the
user the choice to have wifi during a live or installation session if
restricted drivers are needed for it.

For that common hardware that I typically use/support there aren't really any
major issues outside the X stack in recent releases.

Scott K

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: brainstorming for UDS-N - Hardware Compatibility

Jorge O. Castro-3
On Tue, Sep 28, 2010 at 9:18 PM, Scott Kitterman <[hidden email]> wrote:
> Since the installation experience is now significantly enhanced
> if done with an active internet connection, I would like to see us push to the
> user the choice to have wifi during a live or installation session if
> restricted drivers are needed for it.

Along the same lines it would be nice if the installer would try to
get the backported drivers during installation if it finds that the
shipped driver doesn't work. I had a machine during the Karmic cycle
that needed a backported driver to get wireless, the only way I knew
it was a trivial fix was that I knew about the package.

Come to think of it, are there situations where the user wouldn't
benefit from just having the backported driver in there by default?
(Like in point releases and whatnot)

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: brainstorming for UDS-N - Hardware Compatibility

Mario Limonciello-2
In reply to this post by Allison Randal-4
Hi Allison:

Something I'd like to see is Jockey learning what's available in LBM that can help your hardware improve.  I'll use a real-world example.  A user has some brand new sandy bridge ethernet hardware on their motherboard.  They install Maverick and have support for their hardware in the Maverick kernel from some backported patches.  There happens to also be support however in LBM for a full backport from 2.6.36 for that ethernet driver.

In a scenario like this I think it would make sense for Jockey to offer on a 2nd or 3rd boot offer some information about the LBM driver and why it might be beneficial.

On 09/28/2010 02:33 PM, Allison Randal wrote:
The Hardware Compatibility track is about supporting the widest possible
selection of hardware, in an easy-to-use fashion (GUI tools, avoiding
manual configuration, etc), with sane default settings.

What's high on your list for this area?
Allison



--
Mario Limonciello
[hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: brainstorming for UDS-N - Hardware Compatibility

Daniel Chen-2
In reply to this post by Jorge O. Castro-3
On Wed, Sep 29, 2010 at 9:33 AM, Jorge O. Castro <[hidden email]> wrote:
> Along the same lines it would be nice if the installer would try to
> get the backported drivers during installation if it finds that the
> shipped driver doesn't work. I had a machine during the Karmic cycle
> that needed a backported driver to get wireless, the only way I knew
> it was a trivial fix was that I knew about the package.

Taking the case of a wireless driver needed from a backported kernel
or l-b-m, there would need to be additional logic to handle attempting
such a download only if a matching signed Ubuntu repository for that
release were reachable.  It seems reasonable enough.


> Come to think of it, are there situations where the user wouldn't
> benefit from just having the backported driver in there by default?
> (Like in point releases and whatnot)

I suspect available space on the live CD images is of concern, but I
see no reason why the backported driver couldn't be included on the
DVD image (additionally, newer hardware tends to ship with drives
capable of reading these larger images).

Best,
-Dan

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: brainstorming for UDS-N - Hardware Compatibility

Jorge O. Castro-3
On Thu, Sep 30, 2010 at 10:35 AM, Daniel Chen <[hidden email]> wrote:

> On Wed, Sep 29, 2010 at 9:33 AM, Jorge O. Castro <[hidden email]> wrote:
>> Along the same lines it would be nice if the installer would try to
>> get the backported drivers during installation if it finds that the
>> shipped driver doesn't work. I had a machine during the Karmic cycle
>> that needed a backported driver to get wireless, the only way I knew
>> it was a trivial fix was that I knew about the package.
>
> Taking the case of a wireless driver needed from a backported kernel
> or l-b-m, there would need to be additional logic to handle attempting
> such a download only if a matching signed Ubuntu repository for that
> release were reachable.  It seems reasonable enough.

I was chatting with Evan about this on IRC and I've come up with a
basic brainstormy idea that Jockey can provide: "I realize I'm on a
notebook, but can't find wireless, I wonder if I can try harder and
grab the backported kernel drivers? Please plug in a network cable"
And if the user isn't close to ethernet maybe having a hook somewhere
that does "I've noticed you've plugged into a wired connection, now
would be a good time for me to go find your wireless driver, ok?"
would be doable.

Basically my gist is we already support a bunch of hardware it's just
hard for users to find it sometimes and making an effort to improve
that would be a nice low hanging fruit. (If it actually is low hanging
fruit)

...

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: brainstorming for UDS-N - Hardware Compatibility

Martin Owens-2
In reply to this post by Scott Kitterman-3


On Tue, 2010-09-28 at 21:18 -0400, Scott Kitterman wrote:
> > The Hardware Compatibility track is about supporting the widest
> possible
> > selection of hardware, in an easy-to-use fashion (GUI tools,
> avoiding
> > manual configuration, etc), with sane default settings.

My concern with hardware compatibility has been peripherals.

Printers, scanners, graphics tablets, midi mixers and phone-syncing are
all things I've had to field questions about, help support and publish
ppa drivers/patches or blog posts as guides.

There is a lot of talk about chipsets and computer internals, is
hardware support for non-standard usb peripheral devices out of scope?

Martin,


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: brainstorming for UDS-N - Hardware Compatibility

Jussi Schultink-2
In reply to this post by Jorge O. Castro-3
On Thu, Sep 30, 2010 at 6:13 PM, Jorge O. Castro <[hidden email]> wrote:

> On Thu, Sep 30, 2010 at 10:35 AM, Daniel Chen <[hidden email]> wrote:
>> On Wed, Sep 29, 2010 at 9:33 AM, Jorge O. Castro <[hidden email]> wrote:
>>> Along the same lines it would be nice if the installer would try to
>>> get the backported drivers during installation if it finds that the
>>> shipped driver doesn't work. I had a machine during the Karmic cycle
>>> that needed a backported driver to get wireless, the only way I knew
>>> it was a trivial fix was that I knew about the package.
>>
>> Taking the case of a wireless driver needed from a backported kernel
>> or l-b-m, there would need to be additional logic to handle attempting
>> such a download only if a matching signed Ubuntu repository for that
>> release were reachable.  It seems reasonable enough.
>
> I was chatting with Evan about this on IRC and I've come up with a
> basic brainstormy idea that Jockey can provide: "I realize I'm on a
> notebook, but can't find wireless, I wonder if I can try harder and
> grab the backported kernel drivers? Please plug in a network cable"
> And if the user isn't close to ethernet maybe having a hook somewhere
> that does "I've noticed you've plugged into a wired connection, now
> would be a good time for me to go find your wireless driver, ok?"
> would be doable.
>
> Basically my gist is we already support a bunch of hardware it's just
> hard for users to find it sometimes and making an effort to improve
> that would be a nice low hanging fruit. (If it actually is low hanging
> fruit)
>
I like this, one of the greatest annoyances I have seen come up on IRC
is people who have wireless cards that need a driver, but they need to
get on the internet to get that driver. Catch22.

Also along these lines, many people I have come across are wanting to
have the ability to get updated drivers, but not get all the rest of
backports. perhaps some simple way of dividing backports/updates repos
up into sections so people can easily chose which parts they are
getting? (applications, drivers etc)

Jussi.
> ...
>
> --
> ubuntu-devel mailing list
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: brainstorming for UDS-N - Hardware Compatibility

Jan Claeys-3
Jussi Schultink schreef op vr 01-10-2010 om 09:50 [+0300]:
> Also along these lines, many people I have come across are wanting to
> have the ability to get updated drivers, but not get all the rest of
> backports. perhaps some simple way of dividing backports/updates repos
> up into sections so people can easily chose which parts they are
> getting? (applications, drivers etc)

The linux-backports-modules-* packages are not in the -backports
repository, and I would think most people want -updates enabled anyway?


--
Jan Claeys


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: brainstorming for UDS-N - Hardware Compatibility

Mackenzie Morgan-3
In reply to this post by Jussi Schultink-2
On Friday, October 01, 2010 02:50:26 am Jussi Schultink wrote:
> Also along these lines, many people I have come across are wanting to
> have the ability to get updated drivers, but not get all the rest of
> backports. perhaps some simple way of dividing backports/updates repos
> up into sections so people can easily chose which parts they are
> getting? (applications, drivers etc)

inux-backports-modules-maverick-generic is  not in the Backports repo. They
don't need to enable Backports and then worry about other things breaking.
It's in Universe, IIRC.

--
Mackenzie Morgan
http://mackenzie.morgan.name
http://ubuntulinuxtipstricks.blogspot.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel