Greg KH | 2 Apr 2008 19:00
Gravatar

Drivers Needed - Video for Linux devices (Input) - ATI Theater 650 Pro

On Sat, Mar 29, 2008 at 06:53:48PM -0500, atoms wrote:
> 
> Hi All,
> 
> This is in reference to  Drivers Needed -  Video for Linux devices 
> (Input) -  ATI Theater 650 Pro - ven_1002 / dev_4d50
> 
> These cards have been out since 2006

Do you have the specifications for this hardware anywhere so that
drivers can be written for them?

thanks,

greg k-h

Alex Deucher | 3 Apr 2008 01:11
Picon

Drivers Needed - Video for Linux devices (Input) - ATI Theater 650 Pro

On Wed, Apr 2, 2008 at 1:00 PM, Greg KH <greg at kroah.com> wrote:
> On Sat, Mar 29, 2008 at 06:53:48PM -0500, atoms wrote:
>  >
>  > Hi All,
>  >
>  > This is in reference to  Drivers Needed -  Video for Linux devices
>  > (Input) -  ATI Theater 650 Pro - ven_1002 / dev_4d50
>  >
>  > These cards have been out since 2006
>
>  Do you have the specifications for this hardware anywhere so that
>  drivers can be written for them?
>

At this time, AMD hasn't released specs for this chip.

Alex

Greg KH | 3 Apr 2008 01:38
Gravatar

Drivers Needed - Video for Linux devices (Input) - ATI Theater 650 Pro

On Wed, Apr 02, 2008 at 07:11:46PM -0400, Alex Deucher wrote:
> On Wed, Apr 2, 2008 at 1:00 PM, Greg KH <greg at kroah.com> wrote:
> > On Sat, Mar 29, 2008 at 06:53:48PM -0500, atoms wrote:
> >  >
> >  > Hi All,
> >  >
> >  > This is in reference to  Drivers Needed -  Video for Linux devices
> >  > (Input) -  ATI Theater 650 Pro - ven_1002 / dev_4d50
> >  >
> >  > These cards have been out since 2006
> >
> >  Do you have the specifications for this hardware anywhere so that
> >  drivers can be written for them?
> >
> 
> At this time, AMD hasn't released specs for this chip.

Then unfortunatly there's not much we can do for them :(

thanks,

greg k-h

Greg KH | 7 Apr 2008 23:48
Gravatar

Linux Driver Project Status Report as of April 2008

Hi all,

It's been about a year since the linux driver project was started, so I
figured that it was about time for a status report of how things are
going, and how things are going to be changing a bit for the future.

Thanks again for everyone that has participated so far, I, and all of
the Linux users out there, really appreciate it.

greg k-h

------------

Linux Driver Project Status Report as of April 2008

Executive Summary

  The Linux Driver Project (LDP) is alive and well, with over 300
  developers wanting to participate, many drivers already written and
  accepted into the Linux kernel tree, and many more being currently
  developed.  The main problem is a lack of projects.  It turns out that
  there really isn't much hardware that Linux doesn't already support.
  Almost all new hardware produced is coming with a Linux driver already
  written by the company, or by the community with help from the
  company.

  There are two main classes of hardware, video input devices and
  wireless network cards, that is not well supported by Linux, but large
  efforts are already underway to resolve this issue, with the wireless
  driver issue pretty much taken care of already, however there are a
(Continue reading)

Benoit Donnette | 8 Apr 2008 07:33
Favicon

Linux Driver Project Status Report as of April 2008

First of all, thank you for your amazing work, Greg.

Now one more element :

Quite a few USB/IEEE1394 devices are in fact supported by third party
software usually not coded as kernel drivers, and a lot of them do not
bother not being Linux-aware. The one I am most interested in is digital
cameras (DSLR, to be precise), for all the things not related to image
transfers (these use the Mass Storage protocol most of the time). Using a
DSLR controlled from a computer requires a Win machine or a Macintosh
today, and this is heavily used in studios. This is the last obstacle for
full-Linux image companies. We could then suggest a few breakthroughs
(revision control integrated in a document management system for example),
and these could make the difference.

I'd have some time to spend on it as soon as I get a camera. I'll try to
contact the Open-Source friendliest manufacturer first (Pentax, whose lens
mount is mostly open, who allows for a documented raw format : these are
fair signs of openness).

--

-- 
Beno?t Donnette - Expert TM2L/OSSA - www.08000linux.com
LINAGORA - 27 rue de Berri - 75008 PARIS
LINAGORA recrute : http://www.linagora.com/societe/nous_rejoindre/
"A logiciel libre, rien d'impossible !"

Greg KH | 8 Apr 2008 07:55
Gravatar

Linux Driver Project Status Report as of April 2008

On Tue, Apr 08, 2008 at 07:33:41AM +0200, Benoit Donnette wrote:
> First of all, thank you for your amazing work, Greg.
> 
> Now one more element :
> 
> Quite a few USB/IEEE1394 devices are in fact supported by third party
> software usually not coded as kernel drivers, and a lot of them do not
> bother not being Linux-aware. The one I am most interested in is digital
> cameras (DSLR, to be precise), for all the things not related to image
> transfers (these use the Mass Storage protocol most of the time). Using a
> DSLR controlled from a computer requires a Win machine or a Macintosh
> today, and this is heavily used in studios. This is the last obstacle for
> full-Linux image companies. We could then suggest a few breakthroughs
> (revision control integrated in a document management system for example),
> and these could make the difference.
> 
> I'd have some time to spend on it as soon as I get a camera. I'll try to
> contact the Open-Source friendliest manufacturer first (Pentax, whose lens
> mount is mostly open, who allows for a documented raw format : these are
> fair signs of openness).

We have the ability to control firewire devices from userspace through
the "raw" driver, right?

And for USB, we have libusb and openusb, both cross-platform userspace
libraries built on top of usbfs.

So from the kernel point-of-view, I think that there's not much we can
do here, right?  I've pushed many USB devices to userspace programs
using libusb as that is the proper place for them (they don't need to be
(Continue reading)

Benoit Donnette | 8 Apr 2008 08:15
Favicon

Linux Driver Project Status Report as of April 2008

>
> We have the ability to control firewire devices from userspace through
> the "raw" driver, right?
>
> And for USB, we have libusb and openusb, both cross-platform userspace
> libraries built on top of usbfs.
>
> So from the kernel point-of-view, I think that there's not much we can
> do here, right?  I've pushed many USB devices to userspace programs
> using libusb as that is the proper place for them (they don't need to be
> kernel drivers).  This gets the benifit of working on all OSes that
> libusb supports (solaris, *bsd, windows, os-x, etc.)
>
> If you know of specific devices that are not working on Linux, _and_
> whose manufacturers are interested in changing this, please let me know,
> I'll be glad to help out.
>
> thanks,
>
> greg k-h
>

>From the kernel point of view, I agree. It is all the more right than
these devices are actually operated in a fairly similar way elsewhere :
through userspace extensions of similar "raw" or "misc" devices.

I take the action of trying to reach a few DSLR vendors, at least the ones
I have a personal reason to contact due to my equipment. I'll put my hands
on it as well.

(Continue reading)

JoJo jojo | 8 Apr 2008 08:16
Picon

Linux Driver Project Status Report as of April 2008

Thanks Greg,

A few points for your consideration

a) Marketing the LDP project:-
You are missing the numbers, from the LDP propaganda,
numbers/statistics etc.
(even MicroSoft quotes things like TCO ;-) in their propaganda)

Someone may try coming up with numbers from git commit logs,
but how do we know, how many of them came from LDP efforts ?

b) You need to segregate the LDP targets into 2 categories
Enterprise endusers & Non-Enterprise endusers.
Enterprise endusers are the ones telling you, their h/w is
well/somewhat supported,
Non-Enterprise endusers are the ones telling you, their h/w is _NOT_ supported,

"Enterprise" segment is attractive to developers, there's money to be made....
"Non-Enterprise" segment is _NOT_ attractive to developers, there's
_no_ money to be made....

"Non-Enterprise" segments usually end-up  with only volunteering
efforts and thus suffer.
So I have to ask, what is the goal of LDP, target only "Enterprise" segment ?

c) Taking Driver support on a war footing
Please work to centralize the H/W compatibility list, every distro is
rolling their own...its all a mess
Start a major effort to Whitelist/Blacklist Manufacturer & Devices,
(Continue reading)

Greg KH | 8 Apr 2008 08:42
Gravatar

Linux Driver Project Status Report as of April 2008

On Tue, Apr 08, 2008 at 11:46:48AM +0530, JoJo jojo wrote:
> Thanks Greg,
> 
> A few points for your consideration
> 
> a) Marketing the LDP project:-
> You are missing the numbers, from the LDP propaganda,
> numbers/statistics etc.
> (even MicroSoft quotes things like TCO ;-) in their propaganda)
> 
> Someone may try coming up with numbers from git commit logs,
> but how do we know, how many of them came from LDP efforts ?

Exactly, it's not a simple "oh look, these drivers came exactly from our
efforts" type of thing.  The reach and range of this effort is already
quite large, trying to quantify it for no good reason isn't something
that I'm going to worry about.

In the end, what would it really achieve?

> b) You need to segregate the LDP targets into 2 categories
> Enterprise endusers & Non-Enterprise endusers.

I do not believe in those two categories at all.

> Enterprise endusers are the ones telling you, their h/w is
> well/somewhat supported,
> Non-Enterprise endusers are the ones telling you, their h/w is _NOT_ supported,
> 
> "Enterprise" segment is attractive to developers, there's money to be made....
(Continue reading)

Greg KH | 8 Apr 2008 08:46
Gravatar

Linux Driver Project Status Report as of April 2008

On Tue, Apr 08, 2008 at 08:15:52AM +0200, Benoit Donnette wrote:
> Now let's face it : your great initiative has an excellent visibility, and
> this is a strong point to show to hardware vendors. We might need to end
> up with a "Linux-awareness for hardware vendors" page as a hub to kernel
> projects, printers/CUPS, scanners and so on. Having a separation that says
> "no, your support is not done here, please go elsewhere" might be an own
> goal, most companies tend to like having a single entry point to a service
> that sounds unique to them, 'hardware driving'.

This is not the first time someone has told me this.  My response to
them, and to you and who ever else thinks this way is, "We have a wiki
that can contain this kind of information, go ahead and create it if you
think this is an effort that you wish to do.  If you need me to set up
another domain and wiki on it, I can easily put you in contact with the
people who can host it for free."

As you can see, our wiki has not grown to contain this kind of "hub" as
of yet, people like telling others what to do more than they like to do
it themselves it seems :)

thanks,

greg k-h


Gmane