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 sets
4) common code takes this string and does a hotplug event with it.
5) hotplug event runs root context in user space
6) mode is decoded and verified, this may involve a little process that
maintains the DDC database and reads a file of legal modes. Other
schemes are possible.
7a) mode is set using VBIOS and vm86, signal driver mode is set
7b) the register values needed to set the mode are passed into a root
priv ioctl.
8) driver is unlocked.
In this model all of the verification happens in user space. If you
want to set modes other than the ones from DDC you have to add them to
the config file. There is no need for DDC support and mode verification
in the kernel.
To give credit this is Alan Cox's design.
---------------------------------------------------------------------------------
I'm now starting to implement this design. Would it be better to set
the mode via sysfs attributes? This would allow mode settting with
something like: "echo 'my mode string' /sys/class/drm/card0/mode" A
list of available modes could be in /sys/class/drm/card0/modes
Can PAM change the ownership of a sysfs attribute/directory on login?
For this to work logging in needs to assign you ownership of the
attribute since you want to be able to change it but not anyone else.
DRM may need to assign the ownership of multiple attributes, is this
easy to do?
How are errors going to be communicated in this scheme? I can cat the
sysfs mode variable to get a status. Is there a good way to do this
without polling?
If the sysfs scheme doesn't work mode setting will need to be an IOCTL
with a small program since PAM can change the ownership of the DRM
device. The sysfs scheme has the major advantage of avoiding the need
for the small program.
If we go the sysfs route what is BSD going to do, will we have to
build parallel implementations?
--
Jon Smirl
[email protected]
--- 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 sets
> 4) common code takes this string and does a hotplug event with it.
> 5) hotplug event runs root context in user space
> 6) mode is decoded and verified, this may involve a little process that
> maintains the DDC database and reads a file of legal modes. Other
> schemes are possible.
> 7a) mode is set using VBIOS and vm86, signal driver mode is set
> 7b) the register values needed to set the mode are passed into a root
> priv ioctl.
> 8) driver is unlocked.
>
> In this model all of the verification happens in user space. If you
> want to set modes other than the ones from DDC you have to add them to
> the config file. There is no need for DDC support and mode verification
> in the kernel.
>
> To give credit this is Alan Cox's design.
>
>
---------------------------------------------------------------------------------
>
> I'm now starting to implement this design. Would it be better to set
> the mode via sysfs attributes? This would allow mode settting with
> something like: "echo 'my mode string' /sys/class/drm/card0/mode" A
> list of available modes could be in /sys/class/drm/card0/modes
>
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 one would plan todo
this /wo blocking. I don't see any good reason why it can't be an ioctl,
you can have the same exe/bin/app handle BOTH the user and root parts of
the mode change. This way it can keep a cache of things, like modes that
will currently not be valid.
> Can PAM change the ownership of a sysfs attribute/directory on login?
> For this to work logging in needs to assign you ownership of the
> attribute since you want to be able to change it but not anyone else.
> DRM may need to assign the ownership of multiple attributes, is this
> easy to do?
>
> How are errors going to be communicated in this scheme? I can cat the
> sysfs mode variable to get a status. Is there a good way to do this
> without polling?
>
> If the sysfs scheme doesn't work mode setting will need to be an IOCTL
> with a small program since PAM can change the ownership of the DRM
> device. The sysfs scheme has the major advantage of avoiding the need
> for the small program.
>
There is another thing I can't see. Why can't the module for the drm
create fb[0-9]* devices, one for each monitor? This would seam to solve
the problem with having another app and ioctl(API).
> If we go the sysfs route what is BSD going to do, will we have to
> build parallel implementations?
>
> --
> Jon Smirl
> [email protected]
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
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 one would plan todo
> this /wo blocking. I don't see any good reason why it can't be an ioctl,
> you can have the same exe/bin/app handle BOTH the user and root parts of
> the mode change. This way it can keep a cache of things, like modes that
> will currently not be valid.
VCs should be dealt with at a higher layer. This higher layer would
track what mode is on each virtual console and set it back after
console swap. The VC code would provide it's own sysfs mode attribute
in the VC's sysfs entry. A VC layer may suppress direct access to the
head specific mode attribute. This brings up a question, how do I know
which sysfs VC entry corresponds to the one I'm logged into?
I'm trying to allow for a user space VC implementation at some point
in the future so I don't want to build assumptions about a kernel
space VC implementation into the code.
The sysfs scheme has the advantage that there is no special user
command required. You just use echo or cp to set the mode.
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 specific libraries. Initially I'm
going to add the functions to the mesa libraries but they may get
broken out later.
> There is another thing I can't see. Why can't the module for the drm
> create fb[0-9]* devices, one for each monitor? This would seam to solve
> the problem with having another app and ioctl(API).
The DRM driver I'm working on already creates one DRM device for each
head. Doing this also creates a sysfs entry for each head too. Each
head has it's own mode/modes attributes.
Another item is merged fb. Initially heads will be unowned. Logging
into a head makes you the owner. If you ask for the modes available on
your head the list will also contain merged fb mode. If you set a
merged fb mode, the login process on the secondary screen needs to be
killed. If some one is logged into the secondary head merged fb modes
won't be in the list. This scheme has the nice side effect of making
all heads equal, there is no separate controlling device for the card.
--
Jon Smirl
[email protected]
--- 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
> > while not being active, thought I can't imagin how one would plan todo
> > this /wo blocking. I don't see any good reason why it can't be an
> ioctl,
> > you can have the same exe/bin/app handle BOTH the user and root parts
> of
> > the mode change. This way it can keep a cache of things, like modes
> that
> > will currently not be valid.
>
> VCs should be dealt with at a higher layer. This higher layer would
> track what mode is on each virtual console and set it back after
> console swap. The VC code would provide it's own sysfs mode attribute
> in the VC's sysfs entry. A VC layer may suppress direct access to the
> head specific mode attribute. This brings up a question, how do I know
> which sysfs VC entry corresponds to the one I'm logged into?
>
In this(the above) model this may work. How will Xorg handle VT swaps in
the above model?
> I'm trying to allow for a user space VC implementation at some point
> in the future so I don't want to build assumptions about a kernel
> space VC implementation into the code.
>
That seams like a good plan, thought current user space multi-'screen'
implementations leave much too desier. 'detachtty' seams like the best
one, but it dosen't directly support switching tasks.
Befour this idea will get off the ground a good system too handel this in
userspace is needed, I think. I don't think that this app/daemon would
have anything todo with mode setting or video drivers, exept the console
drivers allready provided by most OSs.
> The sysfs scheme has the advantage that there is no special user
> command required. You just use echo or cp to set the mode.
>
We allready have programs that change the video mode. It's true thay lack
support for some things, but I can't see the harm in adding on to existing
mode-setting programs.
If that's not good enuff there's no reason that the userland hotplug
script/program can't also provide these features if called by a non-root
user. If called by root, it just dose what it's told /wo the hp or mode
setting ioctl.
> 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 specific libraries. Initially I'm
> going to add the functions to the mesa libraries but they may get
> broken out later.
>
/etc/mtab is a good concept, you might want to put this some where in /var
thought. Then there's no need to TSR.
> > There is another thing I can't see. Why can't the module for the drm
> > create fb[0-9]* devices, one for each monitor? This would seam to
> solve
> > the problem with having another app and ioctl(API).
>
> The DRM driver I'm working on already creates one DRM device for each
> head. Doing this also creates a sysfs entry for each head too. Each
> head has it's own mode/modes attributes.
>
So can we link fb to drm, for compatibility reasons?
> Another item is merged fb. Initially heads will be unowned. Logging
> into a head makes you the owner. If you ask for the modes available on
> your head the list will also contain merged fb mode. If you set a
> merged fb mode, the login process on the secondary screen needs to be
> killed. If some one is logged into the secondary head merged fb modes
> won't be in the list. This scheme has the nice side effect of making
> all heads equal, there is no separate controlling device for the card.
>
I don't see this as more then a fue more ioctls or rather just appending
some data on the end of existing structures to say what
location/framebuffer to attach too or create.
The other code has tobe done no matter what.
> --
> Jon Smirl
> [email protected]
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
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 of /dev/fb0 with mode
setting done on that file pointer will be easier to keep straight
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 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 of /dev/fb0 with mode
> setting done on that file pointer will be easier to keep straight
>
>
>
>
--
Jon Smirl
[email protected]
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:
volodya@silver:~$ ls -l /proc/self/fd/0
lrwx------ 1 volodya users 64 Sep 18 21:56 /proc/self/fd/0 -> /dev/pts/1
So you get the pointer to the actual device stdin is associated to.
best
Vladimir Dergachev
>
>
> On Sat, 18 Sep 2004 16:33:54 -0700, Keith Packard <[email protected]> wrote:
>>
>> 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 of /dev/fb0 with mode
>> setting done on that file pointer will be easier to keep straight
>>
>>
>>
>>
>
>
>
> --
> Jon Smirl
> [email protected]
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
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 knows what device it was started on. An
escape sequence could query the device from the VC terminal emulator.
Is there some way to figure this out from the environment?
On Sat, 18 Sep 2004 21:57:32 -0400 (EDT), Vladimir Dergachev
<[email protected]> wrote:
> 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:
>
> volodya@silver:~$ ls -l /proc/self/fd/0
> lrwx------ 1 volodya users 64 Sep 18 21:56 /proc/self/fd/0 -> /dev/pts/1
>
> So you get the pointer to the actual device stdin is associated to.
--
Jon Smirl
[email protected]
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 since X stays running.
>
> Maybe the answer is that this is something for the VC layer since the
> VC layer stays running and knows what device it was started on. An
> escape sequence could query the device from the VC terminal emulator.
>
> Is there some way to figure this out from the environment?
Well, there is a DISPLAY variable which you likely knew about. Otherwise
there does not seem to be anything else console specific.
Btw, completely unrelated, but I found that that I have
WINDOW_MANAGER=metacity set. Not sure how I got it, but I am running KDE.
best
Vladimir Dergachev
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 mode sets
> 4) common code takes this string and does a hotplug event with it.
> 5) hotplug event runs root context in user space
> 6) mode is decoded and verified, this may involve a little process that
> maintains the DDC database and reads a file of legal modes. Other
> schemes are possible.
> 7a) mode is set using VBIOS and vm86, signal driver mode is set
> 7b) the register values needed to set the mode are passed into a root
> priv ioctl.
> 8) driver is unlocked.
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.
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 happens so it can "catch up".
This also involves dealing with all pending DRI clients too, that is they
have to be notified that the fb/vmem layout is changing, the pending
commands have to be completed, no more accepted, etc... until every DRI
"client" acked the change... That sort of thing.
Ben.
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 specific libraries. Initially I'm
> going to add the functions to the mesa libraries but they may get
> broken out later.
I'd rather have the kernel driver do the actual probing and provide
the EDID or other infos for non-EDID capable monitors to userland (via
hotplug maybe ?), though userland can then of course decide to
"override" it and it's still userland that decodes it etc....
There are various cases of HW hackery involved in proper monitor
detection that I'd rather not see in userland anymore. Also, some cards
may provide an interrupt for detecting connector state change.
> > There is another thing I can't see. Why can't the module for the drm
> > create fb[0-9]* devices, one for each monitor? This would seam to solve
> > the problem with having another app and ioctl(API).
>
> The DRM driver I'm working on already creates one DRM device for each
> head. Doing this also creates a sysfs entry for each head too. Each
> head has it's own mode/modes attributes.
>
> Another item is merged fb. Initially heads will be unowned. Logging
> into a head makes you the owner. If you ask for the modes available on
> your head the list will also contain merged fb mode. If you set a
> merged fb mode, the login process on the secondary screen needs to be
> killed. If some one is logged into the secondary head merged fb modes
> won't be in the list. This scheme has the nice side effect of making
> all heads equal, there is no separate controlling device for the card.
--
Benjamin Herrenschmidt <[email protected]>
--- 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 should
be no other ties to the current console. Right?
I think this is totaly a userspace question or do we need to find out the
procs console in an ioctl?
>
> On Sat, 18 Sep 2004 16:33:54 -0700, Keith Packard <[email protected]>
> wrote:
> >
> > 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 of /dev/fb0 with mode
> > setting done on that file pointer will be easier to keep straight
> >
> >
> >
> >
>
>
>
> --
> Jon Smirl
> [email protected]
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
--- 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, hence it workes even
when run from a serial or ssh terminal.
> Maybe the answer is that this is something for the VC layer since the
> VC layer stays running and knows what device it was started on. An
> escape sequence could query the device from the VC terminal emulator.
>
> Is there some way to figure this out from the environment?
>
> On Sat, 18 Sep 2004 21:57:32 -0400 (EDT), Vladimir Dergachev
> <[email protected]> wrote:
> > 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:
> >
> > volodya@silver:~$ ls -l /proc/self/fd/0
> > lrwx------ 1 volodya users 64 Sep 18 21:56 /proc/self/fd/0 ->
> /dev/pts/1
> >
> > So you get the pointer to the actual device stdin is associated to.
>
> --
> Jon Smirl
> [email protected]
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
On Sun, 19 Sep 2004 12:00:21 +0200, you wrote in linux.kernel:
> The FDs 0, 1 and posibly 2 will be the console.
*The* console? They can all be connected to different console
devices (think redirection). I'd think for video mode questions,
you'd look at stdout...
--
Ciao,
Pascal
On Sun, 19 Sep 2004, Pascal Schmidt wrote:
> On Sun, 19 Sep 2004 12:00:21 +0200, you wrote in linux.kernel:
> > The FDs 0, 1 and posibly 2 will be the console.
>
> *The* console? They can all be connected to different console
> devices (think redirection). I'd think for video mode questions,
> you'd look at stdout...
Early versions of stty made that mistake - to find out what settings your
printers had, you ended up printing the output of stty on paper.
If you're going to subvert an fd, use stdin, not stdout.
stdin is less valuable most commands use argv rather than stdin, and it
allows you to retreive the output of a command using the shell `backtick`
operators.
Peter
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 change mode but it takes a few seconds. The root priv
> > daemon will dynamically link to card specific libraries. Initially I'm
> > going to add the functions to the mesa libraries but they may get
> > broken out later.
>
> I'd rather have the kernel driver do the actual probing and provide
> the EDID or other infos for non-EDID capable monitors to userland (via
> hotplug maybe ?), though userland can then of course decide to
> "override" it and it's still userland that decodes it etc....
>
> There are various cases of HW hackery involved in proper monitor
> detection that I'd rather not see in userland anymore. Also, some cards
> may provide an interrupt for detecting connector state change.
The design doesn't force DDC to be in the kernel or user space. You
can do it in either place.
In the driver I'm working on I use a standard in kernel i2c driver and
the i2c eeprom driver. This makes the EDID appear as a block in sysfs.
I've also take the monitor detection code from radeonfb and made it
into an IOCTL that the user space app calls.
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 every video card driver.
--
Jon Smirl
[email protected]
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
into the same system I have to assign them ownership of their video
devices so that they can't mess with each other. I want to avoid
needing root priv to change the monitor mode.
> 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 happens so it can "catch up".
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 of the buffer increasing in
size and needing to be moved since it won't fit where it is.
Keith, how should this work for X? We have to make sure all DRI users
of the buffer are halted, get a new location for the buffer, set the
mode, free the old buffer, notify all of the DRI clients that their
target has been wiped and has a new size.
I was wanting to switch mode setting into an atomic operation where
you passed in both the mode timings and buffer location.
--
Jon Smirl
[email protected]
--- 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 happens so it can "catch up".
>
> 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 of the buffer increasing in
> size and needing to be moved since it won't fit where it is.
>
There will be cases where there won't be enuff memory for both
framebuffers. Most video cards will support power-saving modes or an
"off" state. This can be used so that the user won't see the Framebuffer
get overriten with the new data, whatever gets swaped into that memory
location.
> Keith, how should this work for X? We have to make sure all DRI users
> of the buffer are halted, get a new location for the buffer, set the
> mode, free the old buffer, notify all of the DRI clients that their
> target has been wiped and has a new size.
>
> I was wanting to switch mode setting into an atomic operation where
> you passed in both the mode timings and buffer location.
>
I think it would work best if the buffer where setup/maped/allocated(in
revers order), then the call to program the DAC. It dosen't make any
differance if it is attomic, worst case the user will just see trash.
> --
> Jon Smirl
> [email protected]
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
On Sun, 19 Sep 2004, P. Benie wrote:
> If you're going to subvert an fd, use stdin, not stdout.
> stdin is less valuable most commands use argv rather than stdin, and it
> allows you to retreive the output of a command using the shell `backtick`
> operators.
The point is, you need to make a choice if you want to infer the
tty from an fd. You can't assume stdin and stdout point to the same
console. And if we talk about video mode settings, why would I want
to use the fd that the command gets keyboard input from?
The shell backtick obviously uses stdout of the command inside
the backticks. ;)
--
Ciao,
Pascal
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 of the buffer increasing in
> size and needing to be moved since it won't fit where it is.
>
> Keith, how should this work for X?
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 need to be able to pull any off-screen data back to
main memory before things get shuffled around.
This, of course, is related rather strongly with any memory management
system, for which I'd like to have applications allocate main-memory space
for any off-screen resources so that the kernel can pull things off the
video card without needing cooperation from the X server at switch time.
-keith
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 where the user can set the mode without "owning" the device.
>
> The owning part is for multiuser systems. If I have four users logged
> into the same system I have to assign them ownership of their video
> devices so that they can't mess with each other. I want to avoid
> needing root priv to change the monitor mode.
>
> > 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 happens so it can "catch up".
>
> 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 of the buffer increasing in
> size and needing to be moved since it won't fit where it is.
>
> Keith, how should this work for X? We have to make sure all DRI users
> of the buffer are halted, get a new location for the buffer, set the
> mode, free the old buffer, notify all of the DRI clients that their
> target has been wiped and has a new size.
Sounds a lot like moving and resizing GL windows in X. A similar (if not
the same mechanism) could be used here. Whenever a client takes the lock
and detects that someone else had the lock in the mean time it checks
for a new window position and size. Checking for a changed mode or frame
buffer layout would fit in nicely. AFAIK these kind of changes are
communicated through the sarea which is shared by all DRI clients, the
Xserver and the kernel driver, so the checks are pretty low cost (no
system calls or context switches required).
You only have to take the lock before changing the mode. DRI clients and
X will detect the change when they take the lock the next time and
adjust to the new conditions.
>
> I was wanting to switch mode setting into an atomic operation where
> you passed in both the mode timings and buffer location.
>
> --
> Jon Smirl
> [email protected]
| Felix K?hling <[email protected]> http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
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 every video card driver.
I'm not a fan of this solution as you know... oh well... and there's
all that code to detect non-DDC capable monitors as well, which won't
go through /sys/*/i2c...
But do as you like, I don't have time to work on it so I'll shut up.
Ben.
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 of the buffer increasing in
> size and needing to be moved since it won't fit where it is.
>
> Keith, how should this work for X? We have to make sure all DRI users
> of the buffer are halted, get a new location for the buffer, set the
> mode, free the old buffer, notify all of the DRI clients that their
> target has been wiped and has a new size.
>
> I was wanting to switch mode setting into an atomic operation where
> you passed in both the mode timings and buffer location.
It's more than just a problem of buffer allocation. I doubt some of the
engine operations can go undisturbed accross a mode switch (the driver
currently resets the 2D engine for example). So there is some state loss
and the need to stop rendering pipes before and restart them after.
With DRI, that means OpenGL users... not simple.
Ben.
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 it to not run the DDC module on non video
buses. Buses need to be marked with a class like video or ram.
I agree that what you have in the radeon driver works. But this is a
generic problem with DDC monitors, not something that is radeon
specific. If possible I'd like to figure out a solution to this that
will work generically so we don't have to add this same code to all of
the video drivers. I currently don't have a working solution for the
problem using the I2C framework.
I kept the code for the non-DDC monitor detection as is and just made
an IOCTL around it so that I can trigger it from the user space app.
On Mon, 20 Sep 2004 10:07:40 +1000, Benjamin Herrenschmidt
<[email protected]> wrote:
> 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 every video card driver.
>
> I'm not a fan of this solution as you know... oh well... and there's
> all that code to detect non-DDC capable monitors as well, which won't
> go through /sys/*/i2c...
>
> But do as you like, I don't have time to work on it so I'll shut up.
>
> Ben.
>
>
--
Jon Smirl
[email protected]
--- 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 where the user can set the mode without "owning" the
> device.
> >
> > The owning part is for multiuser systems. If I have four users logged
> > into the same system I have to assign them ownership of their video
> > devices so that they can't mess with each other. I want to avoid
> > needing root priv to change the monitor mode.
> >
> > > 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 happens so it can "catch up".
> >
> > 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 of the buffer increasing in
> > size and needing to be moved since it won't fit where it is.
> >
> > Keith, how should this work for X? We have to make sure all DRI users
> > of the buffer are halted, get a new location for the buffer, set the
> > mode, free the old buffer, notify all of the DRI clients that their
> > target has been wiped and has a new size.
>
> Sounds a lot like moving and resizing GL windows in X. A similar (if not
I'd like to point out that this is not smooth on my system, exept for when
using fglrx. When I move, or resize, a DRI window I get vary
noticable(more then 10th second) stoped system, mouse updates aren't even
recorded.
> the same mechanism) could be used here. Whenever a client takes the lock
> and detects that someone else had the lock in the mean time it checks
> for a new window position and size. Checking for a changed mode or frame
> buffer layout would fit in nicely. AFAIK these kind of changes are
> communicated through the sarea which is shared by all DRI clients, the
> Xserver and the kernel driver, so the checks are pretty low cost (no
> system calls or context switches required).
>
> You only have to take the lock before changing the mode. DRI clients and
> X will detect the change when they take the lock the next time and
> adjust to the new conditions.
>
> >
> > I was wanting to switch mode setting into an atomic operation where
> > you passed in both the mode timings and buffer location.
> >
> > --
> > Jon Smirl
> > [email protected]
>
> | Felix K?hling <[email protected]> http://fxk.de.vu |
> | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
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 need to be able to pull any off-screen data back to
> main memory before things get shuffled around.
The last one of these you can't get in the hotplug case but thats
currently a pretty unusual situation compared to the others
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 a hotplug event with it.
I though this was
"Driver decides to either do it itself in kernel, or call userspace
helper if that would be too complex".
> How are errors going to be communicated in this scheme? I can cat the
> sysfs mode variable to get a status. Is there a good way to do this
> without polling?
I'd say that write() to that sysfs file can simply return error. See
echo disk > /sys/power/state, it returns error if transition failed.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
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 a hotplug event with it.
>
> I though this was
>
> "Driver decides to either do it itself in kernel, or call userspace
> helper if that would be too complex".
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.
I'd just rather not have 100K of resident code waiting around for
something that doesn't occur very often. For the radeon sample I'm
working on I have moved everything to user space except for a couple
of small helper functions that directly play with the registers. Note
that all mode setting in X occurs completely in user space so you
can't argue that it can't be done.
> > How are errors going to be communicated in this scheme? I can cat the
> > sysfs mode variable to get a status. Is there a good way to do this
> > without polling?
>
> I'd say that write() to that sysfs file can simply return error. See
> echo disk > /sys/power/state, it returns error if transition failed.
>
> Pavel
> --
> People were complaining that M$ turns users into beta-testers...
> ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
>
--
Jon Smirl
[email protected]
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