On Tue, 21 Sep 2004 14:45:07 +0200, Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
1) user owns graphics devices
2) user sets mode with string (or similar) format using ioctl common to
all drivers.
3) driver is locked to prevent multiple mode sets
4) common code takes this string and does
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
On Sul, 2004-09-19 at 21:40, Keith Packard wrote:
I just need to know where the frame buffer lives; it can move or change
pitch at any time. I can even deal with the frame buffer moving without
warning if necessary. What I can't handle is off-screen memory suddenly
disappearing on me; I
--- Jon Smirl [EMAIL PROTECTED] wrote:
Isn't there an enviroment variable that tells what device is the
console for the session? How do you tell what serial port you're on
when multiple people are logged in on serial lines?
The FDs 0, 1 and posibly 2 will be the console. Per posix? There
--- Jon Smirl [EMAIL PROTECTED] wrote:
You did that from an xterm, right? Which console device is the xterm
running on?
X starts up a process that knows which device it is running and it can
remember that device since X stays running.
Remember X opens the VC sepratly from it's console,
On Sun, 19 Sep 2004 14:48:38 +1000, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
On Sun, 2004-09-19 at 08:12, Jon Smirl wrote:
I'm still undecided if there needs to be a root priv daemon caching
the EDID and polling for a monitor change. EDID can be regenerated on
each request to
On Sun, 19 Sep 2004 14:45:37 +1000, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
One issue here... When we discussed all of this with Keith, we wanted
a mecanism where the user can set the mode without owning the device.
The owning part is for multiuser systems. If I have four users logged
--- Jon Smirl [EMAIL PROTECTED] wrote:
On Sun, 19 Sep 2004 14:45:37 +1000, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
Typically, with X: We don't want X itself to have to be the one
setting
the mode, but rather set the mode and have X be notified properly
before
and after it
Around 12 o'clock on Sep 19, Jon Smirl wrote:
This is going to require some more thought. Mode setting needs two
things, a description of the mode timings and a location of the scan
out buffer. With multiple heads you can't just assume that the buffer
starts at zero. There also the problem
On Mon, 2004-09-20 at 02:12, Jon Smirl wrote:
The radeon driver has that extra code for intializing older DDC. That
can be handled generically in the I2C layer by writing a ddc driver
that is a superset of the eeprom driver. I'd rather get that code
into a generic driver than repeat it in
On Mon, 2004-09-20 at 02:46, Jon Smirl wrote:
This is going to require some more thought. Mode setting needs two
things, a description of the mode timings and a location of the scan
out buffer. With multiple heads you can't just assume that the buffer
starts at zero. There also the problem
I've been talking to the I2C people about the right way to solve this
for the code in radeon_probe_i2c_connector(). This should be solvable
in the I2C framework by writing an EDID driver that implements the
code in it's attach_adapter/detach_adapter functions. What I2C is
missing is a way to tell
--- Felix Kühling [EMAIL PROTECTED] wrote:
On Sun, 19 Sep 2004 12:46:13 -0400
Jon Smirl [EMAIL PROTECTED] wrote:
On Sun, 19 Sep 2004 14:45:37 +1000, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
One issue here... When we discussed all of this with Keith, we
wanted
a mecanism
--- Jon Smirl [EMAIL PROTECTED] wrote:
Original proposal.
At OLS we talked about a system like this for setting video modes:
1) user owns graphics devices
2) user sets mode with string (or similar) format using ioctl common to
all drivers.
3) driver is locked to prevent multiple mode
On Sat, 18 Sep 2004 12:58:07 -0700 (PDT), Mike Mestnik
[EMAIL PROTECTED] wrote:
This is intersting...
I'd like to know how you plan to use VCs? That is more then one tty
sharing the same monitor. I'd also like to see VCs able to change modes
while not being active, thought I can't imagin how
--- Jon Smirl [EMAIL PROTECTED] wrote:
On Sat, 18 Sep 2004 12:58:07 -0700 (PDT), Mike Mestnik
[EMAIL PROTECTED] wrote:
This is intersting...
I'd like to know how you plan to use VCs? That is more then one tty
sharing the same monitor. I'd also like to see VCs able to change
modes
Around 18 o'clock on Sep 18, Jon Smirl wrote:
The sysfs scheme has the advantage that there is no special user
command required. You just use echo or cp to set the mode.
But it makes it difficult to associate the sysfs entry with the particular
session. Seems like permitting multiple opens
Isn't there an enviroment variable that tells what device is the
console for the session? How do you tell what serial port you're on
when multiple people are logged in on serial lines?
On Sat, 18 Sep 2004 16:33:54 -0700, Keith Packard [EMAIL PROTECTED] wrote:
Around 18 o'clock on Sep 18, Jon
On Sat, 18 Sep 2004, Jon Smirl wrote:
Isn't there an enviroment variable that tells what device is the
console for the session? How do you tell what serial port you're on
when multiple people are logged in on serial lines?
From any program you can do this:
[EMAIL PROTECTED]:~$ ls -l
You did that from an xterm, right? Which console device is the xterm running on?
X starts up a process that knows which device it is running and it can
remember that device since X stays running.
Maybe the answer is that this is something for the VC layer since the
VC layer stays running and
On Sat, 18 Sep 2004, Jon Smirl wrote:
You did that from an xterm, right? Which console device is the xterm running on?
Yes.
I thought /dev/pts/1 was a console - much like regular tty or a serial
port.
X starts up a process that knows which device it is running and it can
remember that device
On Sun, 2004-09-19 at 04:43, Jon Smirl wrote:
Original proposal.
At OLS we talked about a system like this for setting video modes:
1) user owns graphics devices
2) user sets mode with string (or similar) format using ioctl common to
all drivers.
3) driver is locked to prevent multiple
On Sun, 2004-09-19 at 08:12, Jon Smirl wrote:
I'm still undecided if there needs to be a root priv daemon caching
the EDID and polling for a monitor change. EDID can be regenerated on
each request to change mode but it takes a few seconds. The root priv
daemon will dynamically link to card
23 matches
Mail list logo
