Subject: Re: Design for setting video modes, ownership of sysfs attributes
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>, DRI Devel <dri-devel@lists.sourceforge.net>,
       lkml <linux-kernel@vger.kernel.org>
In-Reply-To: <9e473391040921085669c2dcd7@mail.gmail.com>
References: <9e47339104091811431fb44254@mail.gmail.com>
	 <20040921124507.GC2383@elf.ucw.cz>
	 <9e473391040921085669c2dcd7@mail.gmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1095781340.31269.3.camel@localhost.localdomain>
Mime-Version: 1.0
Date: Tue, 21 Sep 2004 16:42:21 +0100
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1379
Lines: 32

On Maw, 2004-09-21 at 16:56, Jon Smirl wrote:
> > "Driver decides to either do it itself in kernel, or call userspace
> > helper if that would be too complex".

It is

> The driver almost always needs to go to user space to get the file of
> mode line overrides that the user can create. But there is nothing
> stopping you from building everything in the kernel.

For random PC cards this is true. If you take something like the
voodoo1 which essentially has two fixed modes, or vesafb its obviously 
a bit different (ditto a lot of embedded devices)

You also want one mode embedded in every driver so that if the user
space fails, aliens eat your network connection, it panics while mode
switch computing or the like you can get a mode to see what went bang.
Thats probably "single console 640x480 vga timings" for the general case
and also does for boot up until userspace on disk (or initrd) has the
video initialized the way the user wants it in the end.

We also mooted caching settings when it made sense (eg when the
computation is hard and the mmio whacking trivial) to get better mode
change performance on vt flip.
 
Alan

-
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/