mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tuukka Toivonen <tuukkat@ee.oulu.fi>
To: linux-kernel@vger.kernel.org
Cc: linux-usb-devel@lists.sourceforge.net
Subject: Re: [linux-usb-devel] Re: kernel 2.6.8 pwc patches and counterpatches
Date: Thu, 26 Aug 2004 15:07:04 +0300 (EEST)	[thread overview]
Message-ID: <Pine.GSO.4.61.0408261436500.16780@stekt37> (raw)
In-Reply-To: <200408261317.18781.oliver@neukum.org>

On Thu, 26 Aug 2004, Oliver Neukum wrote:

> Am Donnerstag, 26. August 2004 11:22 schrieb Tuukka Toivonen:
>> Besides, format conversions _are not allowed_ in the kernel. They belong
>> into userspace.
> Well, there's no need to be dogmatic about it. In a basic sense any driver
> is performing a format conversion.

Well, it is possible that user applications get exactly the same bytes/bits
that the hardware generates, isn't that the case with most formats with 
common TV cards (bttv)? So I'm not sure why you say any driver does 
format conversions?

I find it rather confusing that some things are allowed in kernel while 
some not. Think about color balancing. This is image processing that I'm 
sure would be objected in the kernel, while it is mandatory to get 
useful colors from some cameras.

Something like picking up the image data from received USB packets and 
copying into image buffer, I don't consider that format conversion as long 
as no arithmetic operations are performed with the data.

And yeah, I do think that all of the arithmetic on the data should be done 
in userspace libraries, always. I'm just waiting until there is one common 
such library.

> Legally of course the license has been given and cannot unilaterally be
> revoked.

The GPL is an unilateral permission from author, and legally I don't know a 
rule which would prevent revocing it, because (usually) nobody has paid 
to obtain it. But IANAL, so I'll drop this subject now.

> But his name is on the driver and he gets the mails about it.

Well, the name could be prepended with a text explaining that Nemosoft does 
not maintain the code.

  reply	other threads:[~2004-08-26 12:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1092793392.17286.75.camel@localhost>
     [not found] ` <1092845135.8044.22.camel@localhost>
     [not found]   ` <20040823221028.GB4694@kroah.com>
2004-08-24 22:58     ` Nemosoft Unv.
2004-08-24 23:04       ` Greg KH
2004-08-25  5:35         ` [linux-usb-devel] " Norbert Preining
2004-08-25  5:52           ` Greg KH
     [not found]         ` <200408260058.59490@smcc.demon.nl>
2004-08-26  7:18           ` Greg KH
2004-08-25 14:02       ` Simon Oosthoek
2004-08-26  9:22         ` [linux-usb-devel] " Tuukka Toivonen
2004-08-26 11:17           ` Oliver Neukum
2004-08-26 12:07             ` Tuukka Toivonen [this message]
2004-08-26  0:55       ` Rob van Nieuwkerk
2004-08-26  1:27         ` Rob van Nieuwkerk
2004-08-26  9:00       ` syrius.ml

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.GSO.4.61.0408261436500.16780@stekt37 \
    --to=tuukkat@ee.oulu.fi \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®