RE: [patch 11/12] new sony_acpi driver

RE: [patch 11/12] new sony_acpi driver

[Brown, Len]

>But still, I don't see why there is no place for a sony acpi somewhere
>where there are already drivers for ibm, toshiba and asus laptops.

The goal is to DELETE ibm, toshiba, and asus drivers -- or at least the
duplicated functions in them.

platform specific drivers make it harder, not easier, to support more
hardware -- there are a zillion vendors out there, implementing special
drivers for each of them is a strategy of last resort.

>I attached to the bugzilla entry the DSDTs for two Vaio laptops, which
>should hopefuly prove that those laptops do not support the standard
>ACPI way to access the video. Did you look at them ?

thanks for filing the bug, it is in the queue.

-Len


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: Re: [patch 11/12] new sony_acpi driver

[Timo Hoenig]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

On Wed, 2005-03-02 at 21:53 +0100, Stelian Pop wrote:
[...]
>
>I have no problem keeping it out of the tree, it has been this was
>for quite a long time now. Anyway the distro maintainers are starting
>to put it into their kernels so it won't be a problem for endusers
>any longer. BTW, it was those distro maintainers who asked me to
>resubmit the driver lately...
>
I guess you're talking about me.  I did not contact you being a distro
maintainer.  As developer, my intention was -- and still is -- that we
really should get as many laptop specific functions into mainline as
possible.  I care about happy users.

It's a shame that there are actually drivers out there but users simply
do not benefit from them because they are not merged with mainline.

Anyway, as Len proposed, a generic solution is definitely the best
solution.  Let's get this work done.

>But still, I don't see why there is no place for a sony acpi somewhere
>where there are already drivers for ibm, toshiba and asus laptops.

They will disappear once the generic solution is implemented.

[...]
>
>Stelian.

See you,

  -- Timo

..............................................................
Timo Hönig <thoenig at nouse dot net>
..................................................:: gpg ::...
Fingerprint: 0998 0ACA A1D2 2612 4D96 DD8B E03F 084B B305 4066

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch 11/12] new sony_acpi driver

[Stelian Pop]

On Wed, Mar 02, 2005 at 05:37:44PM -0500, Brown, Len wrote:

> >But still, I don't see why there is no place for a sony acpi somewhere
> >where there are already drivers for ibm, toshiba and asus laptops.
> 
> The goal is to DELETE ibm, toshiba, and asus drivers -- or at least the
> duplicated functions in them.

Did you look at the code in those drivers ? There is no way you can
delete them because each of them is very specific in the functionalities
it offers and the way to achieve it.

Sure, for basic stuff like the brightness you can hope to have a 
common code (like video.c today). It may even work on future laptops.
But it won't work on older (todays) laptops (I'm not sure about the
other brands, but it won't work on Sony Vaios). And even if when it
works it won't do everything because vendors will always implement
extensions.

And you can choose to either not have access to those extensions
under Linux (which sucks) or have platform specific drivers.

> platform specific drivers make it harder, not easier, to support more
> hardware -- there are a zillion vendors out there, implementing special
> drivers for each of them is a strategy of last resort.

There are hardly "a zillion vendors" in the laptop market. I'd say
that IBM + HP + Sony + Toshiba + Dell form 90+ % of the market.

> >I attached to the bugzilla entry the DSDTs for two Vaio laptops, which
> >should hopefuly prove that those laptops do not support the standard
> >ACPI way to access the video. Did you look at them ?
> 
> thanks for filing the bug, it is in the queue.

The point of the question was to point out that I've already provided
proof that Vaios do not support standard ACPI video methods.

Stelian.
-- 
Stelian Pop <stelian-ibX4/ixPftWsTnJN9+BGXg@public.gmane.org>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: [patch 11/12] new sony_acpi driver

[Timo Hoenig]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

Hi,

On Thu, 2005-03-03 at 10:27 +0100, Stelian Pop wrote:
>Did you look at the code in those drivers ? There is no way you can
>delete them because each of them is very specific in the functionalities
>it offers and the way to achieve it.
>
>Sure, for basic stuff like the brightness you can hope to have a 
>common code (like video.c today). It may even work on future laptops.
>But it won't work on older (todays) laptops (I'm not sure about the
>other brands, but it won't work on Sony Vaios). And even if when it
>works it won't do everything because vendors will always implement
>extensions.

Since the function implementations vary but their purpose is the same it
would be possible by creating generic wrapper functions (hotkey
implementation, trigger common hardware functions like fan,
bluetooth...).  I'm not sure which way would be the best to cover laptop
specific functions which are not covered by the generic wrapper
functions.

[...]
>
>Stelian.

See you,

  -- Timo

..............................................................
Timo Hönig <thoenig at nouse dot net>
..................................................:: gpg ::...
Fingerprint: 0998 0ACA A1D2 2612 4D96 DD8B E03F 084B B305 4066

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: [patch 11/12] new sony_acpi driver

[Stelian Pop]

On Thu, Mar 03, 2005 at 09:40:45AM +0100, Timo Hoenig wrote:

> On Wed, 2005-03-02 at 21:53 +0100, Stelian Pop wrote:
> [...]
> >
> >I have no problem keeping it out of the tree, it has been this was
> >for quite a long time now. Anyway the distro maintainers are starting
> >to put it into their kernels so it won't be a problem for endusers
> >any longer. BTW, it was those distro maintainers who asked me to
> >resubmit the driver lately...
> >
> I guess you're talking about me.

Not only you.

> I did not contact you being a distro
> maintainer.  As developer, my intention was -- and still is -- that we
> really should get as many laptop specific functions into mainline as
> possible.  I care about happy users.

So do I. 

Unhappy users also come bugging me (because I also maintain a non-ACPI
sony driver which did work with older models but works less and less 
with newer ones) and I have to tell them about sony_acpi. Maybe I
should tell them to bug acpi_devel instead ?

> It's a shame that there are actually drivers out there but users simply
> do not benefit from them because they are not merged with mainline.

I fully agree.

> Anyway, as Len proposed, a generic solution is definitely the best
> solution.  Let's get this work done.

Except the generic solution doesn't exist. It could be partly 
implemented (like acpi_video), but it will never be complete.

> >But still, I don't see why there is no place for a sony acpi somewhere
> >where there are already drivers for ibm, toshiba and asus laptops.
> 
> They will disappear once the generic solution is implemented.

Maybe the problem here is that the ACPI based drivers should not
be at all in the ACPI tree.

drivers/acpi contain today both the ACPI layer and the ACPI drivers.
Maybe a split up like the networking code would be saner: $KDIR/acpi
for the layer and $KDIR/drivers/acpi for the drivers using the acpi
API to implements specific drivers.

Stelian.
-- 
Stelian Pop <stelian-ibX4/ixPftWsTnJN9+BGXg@public.gmane.org>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: [patch 11/12] new sony_acpi driver

[Stelian Pop]

On Thu, Mar 03, 2005 at 10:34:04AM +0100, Timo Hoenig wrote:

> On Thu, 2005-03-03 at 10:27 +0100, Stelian Pop wrote:
> >Did you look at the code in those drivers ? There is no way you can
> >delete them because each of them is very specific in the functionalities
> >it offers and the way to achieve it.
> >
> >Sure, for basic stuff like the brightness you can hope to have a 
> >common code (like video.c today). It may even work on future laptops.
> >But it won't work on older (todays) laptops (I'm not sure about the
> >other brands, but it won't work on Sony Vaios). And even if when it
> >works it won't do everything because vendors will always implement
> >extensions.
> 
> Since the function implementations vary but their purpose is the same it
> would be possible by creating generic wrapper functions (hotkey
> implementation, trigger common hardware functions like fan,
> bluetooth...).  I'm not sure which way would be the best to cover laptop
> specific functions which are not covered by the generic wrapper
> functions.

It would be nice to have a common API for userspace. Today this
is done at application level (KDE for example, etc), but it would
be nice if, for the generic functionalities, the kernel would
offer the same API (/proc/acpi, /sys, ioctl based, whatever) to the
userland.

But the discussion here is pretty unrelated. We are talking about
the implementation not interface, and what Len wants is to remove
the specific {ibm,toshiba,asus} implementations and make generic ones 
based on the ACPI stantard.

Stelian.
-- 
Stelian Pop <stelian-ibX4/ixPftWsTnJN9+BGXg@public.gmane.org>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: [patch 11/12] new sony_acpi driver

[Timo Hoenig]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

Hi,

On Thu, 2005-03-03 at 10:45 +0100, Stelian Pop wrote:
[...]
>
>But the discussion here is pretty unrelated. We are talking about
>the implementation not interface, and what Len wants is to remove
>the specific {ibm,toshiba,asus} implementations and make generic ones 
>based on the ACPI stantard.

Ah, OK.  I did not get this before.  Then, we've got a problem.  I mean,
when looking at the different implementations of the drivers it is
obvious that this will  not  work at all.  For example, I'm thinking of
the Toshiba HCI which needs to be polled to get hotkey information...

So, I'd really appreciate to see a comment from Len about his thoughts
which way to go.

>Stelian.

See you,

   -- Timo

..............................................................
Timo Hönig <thoenig at nouse dot net>
..................................................:: gpg ::...
Fingerprint: 0998 0ACA A1D2 2612 4D96 DD8B E03F 084B B305 4066

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: [patch 11/12] new sony_acpi driver

[Timo Hoenig]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Hi,

On Thu, 2005-03-03 at 10:39 +0100, Stelian Pop wrote:
[...]
>Maybe the problem here is that the ACPI based drivers should not
>be at all in the ACPI tree.
>
>drivers/acpi contain today both the ACPI layer and the ACPI drivers.
>Maybe a split up like the networking code would be saner: $KDIR/acpi
>for the layer and $KDIR/drivers/acpi for the drivers using the acpi
>API to implements specific drivers.

That sounds good to me.  If this is the way to go, I'd like to see a
discussion with the developers of all already available drivers.

>Stelian.

See you,

   -- Timo

..............................................................
Timo Hönig <thoenig at nouse dot net>
..................................................:: gpg ::...
Fingerprint: 0998 0ACA A1D2 2612 4D96 DD8B E03F 084B B305 4066

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]