Re: Design for setting video modes, ownership of sysfs attributes
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 --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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] --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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! --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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 --- 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
Re: Design for setting video modes, ownership of sysfs attributes
--- 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 --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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] --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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. --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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. --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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 | --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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 pgpfxSnpquSyG.pgp Description: PGP signature
Re: Design for setting video modes, ownership of sysfs attributes
--- 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 --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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] --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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] --- 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
Re: Design for setting video modes, ownership of sysfs attributes
--- 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: > > > > [EMAIL PROTECTED]:~$ 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 --- 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
Re: Design for setting video modes, ownership of sysfs attributes
--- 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 --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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]> --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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. --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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 --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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: > > [EMAIL PROTECTED]:~$ 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] --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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 /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 --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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] --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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 pgp671yO52h3s.pgp Description: PGP signature
Re: Design for setting video modes, ownership of sysfs attributes
--- 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 --- 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
Re: Design for setting video modes, ownership of sysfs attributes
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] --- 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
Re: Design for setting video modes, ownership of sysfs attributes
--- 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 --- 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
Design for setting video modes, ownership of sysfs attributes
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] --- 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
