Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 4 Nov 2001 12:41:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 4 Nov 2001 12:41:08 -0500 Received: from mpdr0.detroit.mi.ameritech.net ([206.141.239.206]:3458 "EHLO mailhost.det.ameritech.net") by vger.kernel.org with ESMTP id ; Sun, 4 Nov 2001 12:41:03 -0500 Date: Sun, 4 Nov 2001 12:44:48 -0500 (EST) From: volodya@mindspring.com Reply-To: volodya@mindspring.com To: "Albert D. Cahalan" cc: Mark McClelland , video4linux-list@redhat.com, livid-gatos@linuxvideo.org, linux-kernel@vger.kernel.org Subject: Re: [V4L] Re: [RFC] alternative kernel multimedia API In-Reply-To: <200111040839.fA48deO123804@saturn.cs.uml.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 4 Nov 2001, Albert D. Cahalan wrote: > Mark McClelland writes: > > volodya@mindspring.com wrote: > >> On Mon, 29 Oct 2001, Gerd Knorr wrote: > > >>> You can't. But I don't see why this is a issue: The only thing a > >>> application can handle easily are controls like contrast/hue where the > >>> only thing a application needs to do is to map it to a GUI and let the > >>> user understand and adjust stuff. The other stuff has way to much > >>> non-trivial dependences, I doubt a application can blindly use new > >>> driver features. > >> > >> Have you ever thought that the reason we only use these controls is > >> because they are the only ones easy to implement now ? > > > > What I don't understand is how will your driver implement these controls > > in a generic V4L3 GUI control app automatically? No matter how powerful kmultimedia, not V4L3. The interface is meant to be used with _all_ multimedia devices, not just video ones. > > the semantic information you give to the app is, it can still only build > > interfaces from standard GUI components that it already knows about. The > > app cannot build a gamma curve control on its own. If it could, we > > wouldn't need programmers anymore :) > > The driver provides this: /proc/v4l3/vid0/gamma.java > > :-) > > The very idea of a gamma table is featuritis. Just a single number > will do for most anyone. You get from 0.01 to 2.55 and "off" with > just 8 bits. And the color correction is unnecessary too. In fact I see a big opportunity for you to try selling IBM PCs with DOS and generic monitors to artistic community. Just imagine the slogan "Be free from the confines of color!" ;) But on a more serious note: the hardware already has it. All I want is to export the interface to the userspace so that users can decide whether they want to or not. > > If you want to get fancy, I guess you need: > > 1 gamma value per primary > 3 tri-stimulus values for each primary ("What color is red?") > 3 tri-stimulus values for the whitepoint (maybe) > 1 black level for each primary > > That is 18 values at most. See ? You are in the same pit as everyone else. You are trying to construct a single model that fits everything. This is the exact problem that makes Windows so awkward: if you are doing what Microsoft thought you might do you are ok(more or less), if you are trying something new you are screwed. Leave the choice to the user and application programmer. Make it easy for them to support it. Regardless, I am going to give it a try implementing it. It looks like the main argument boiled down to: why bother while we have v4l2 and if you really want we can extend it, which is more or less what I expected, I don't believe any further discussion will make sense until there is some code to look at. Big thanks to everyone for comments :) Vladimir Dergachev > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/