R300 driver on AMD64
Hi everybody i tried Vladimir Dergachevs R300 driver on my AMD64 Gentoo System and had some success. I downloaded the patches from the r300.sourceforge.net site and applied the drm-driver patch against kernel-2.6.9-rc2 (because the drm module i got from dri-cvs wouldn't work). Then i applied the patch for the 2d-driver against Xorg-6.8.0 (the gentoo r1 release). After fiddling around with the 2 rejects that where produced i compiled xorg and started it. Everything seems to be fine (the logs say that drm is enabled and dmesg reports that r300 microcode got loaded). When i tried the r300_demo programm it first stated unsupported card. So i forced it in RV350 mode and it did run. However the screenshots i made look a little bit different then the ones Vladimir did, but my machine didn't locked up ;-). I don't know if it is allowed to send attachments to this list, if it is i will send another email with the screenshots as an attachment and with my logs and dmesg output if anyone is interested. I could also send patches against the drm-module of 2.6.9-rc2 and the ati-driver of xorg-6.8.0 if they are of interest. I would also try to help to get this driver into a better state, however i am not an programmer, but i would like to test new versions of the driver on my amd64 system. Lspci gives the following output for my card (to be included into r300_demo): :01:00.0 0300: 1002:4150 :01:00.1 0380: 1002:4170 It is an Sapphire Radeon 9600 pro (RV350 AP). Thanks for your work and greetings Jan Kreuzer --- 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: R300 driver on AMD64
On Sat, 18 Sep 2004, Jan Kreuzer wrote: Hi everybody i tried Vladimir Dergachevs R300 driver on my AMD64 Gentoo System and had some success. I downloaded the patches from the r300.sourceforge.net site and applied the drm-driver patch against kernel-2.6.9-rc2 (because the drm module i got from dri-cvs wouldn't work). Then i applied the patch for the 2d-driver against Xorg-6.8.0 (the gentoo r1 release). After fiddling around with the 2 rejects that where produced i compiled xorg and started it. Everything seems to be fine (the logs say that drm is enabled and dmesg reports that r300 microcode got loaded). When i tried the r300_demo programm it first stated unsupported card. So i forced it in RV350 mode and it did run. However the screenshots i made look a little bit different then the ones Vladimir did, but my machine didn't locked up ;-). I don't know if it is allowed to send The triangle and the square screenshot is old, r300_demo now displays two triangles one of which is more colorful than before :) attachments to this list, if it is i will send another email with the screenshots as an attachment and with my logs and dmesg output if anyone is interested. I could also send patches against the drm-module of 2.6.9-rc2 and the ati-driver of xorg-6.8.0 if they are of interest. I would also try to help to get this driver into a better state, however i am not an programmer, but i would like to test new versions of the driver on my amd64 system. Thank you ! Could you e-mail me your SF handle so I can add you to the developer list ? Lspci gives the following output for my card (to be included into r300_demo): :01:00.0 0300: 1002:4150 :01:00.1 0380: 1002:4170 It is an Sapphire Radeon 9600 pro (RV350 AP). I just added it to CVS - thank you ! Vladimir Dergachev Thanks for your work and greetings Jan Kreuzer --- 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: [PATCH 2.6.9-rc2 3/33] char/drm_os_linux: replace direct assignment with set_current_state()
Dave, I just fixed this one in DRM CVS.
On Thu, 16 Sep 2004 00:13:46 -0700, Nishanth Aravamudan [EMAIL PROTECTED] wrote:
Re-submission of patch incorporating Alan Cox's suggestion of using
__set_current_state() and changing the other direct assignment in the
macro.
Thanks,
Nish
Description: Use set_current_state() instead of direct assignment of
current-state.
Signed-off-by: Nishanth Aravamudan [EMAIL PROTECTED]
--- 2.6.9-rc2-vanilla/drivers/char/drm/drm_os_linux.h 2004-09-13
17:15:48.0 -0700
+++ 2.6.9-rc2/drivers/char/drm/drm_os_linux.h 2004-09-16 00:10:47.0 -0700
@@ -134,7 +134,7 @@ do {
\
add_wait_queue((queue), entry); \
\
for (;;) { \
- current-state = TASK_INTERRUPTIBLE;\
+ __set_current_state(TASK_INTERRUPTIBLE);\
if (condition) \
break; \
if (time_after_eq(jiffies, end)) { \
@@ -147,7 +147,7 @@ do {
\
break; \
} \
} \
- current-state = TASK_RUNNING; \
+ __set_current_state(TASK_RUNNING); \
remove_wait_queue((queue), entry);\
} while (0)
---
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
--
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: [PATCH 2.6.9-rc2 11/33] char/i830_irq: replace schedule_timeout() with msleep_interruptible()
Dave, what do you want to do about this one, inline function?
msleep_interuptible is only available on recent kernels.
On Thu, 16 Sep 2004 09:43:49 -0700, Nishanth Aravamudan [EMAIL PROTECTED] wrote:
Any comments would be appreciated.
Description: Use msleep_interruptible() instead of schedule_timeout() to
guarantee the task delays as expected.
Signed-off-by: Nishanth Aravamudan [EMAIL PROTECTED]
--- 2.6.9-rc1-mm4-vanilla/drivers/char/drm/i830_irq.c 2004-09-09
23:05:37.0 -0700
+++ 2.6.9-rc1-mm4/drivers/char/drm/i830_irq.c 2004-09-10 10:34:30.0 -0700
@@ -105,7 +105,7 @@ int i830_wait_irq(drm_device_t *dev, int
ret = -EBUSY; /* Lockup? Missed irq? */
break;
}
- schedule_timeout(HZ*3);
+ msleep_interruptible(3000);
if (signal_pending(current)) {
ret = -EINTR;
break;
---
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
--
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
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: 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
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
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
[R300] pixel shader
Hi Nicolai, I committed a modification of pretty_print_command_stream.tcl that decodes most of PFS_INSTR* registers. It still prints the actual value written - as a last value after equals sign. So, I am hoping that even if this messed up your disassembler it is easy to fix - I am not that proficient in Python to venture modifying your code :) Also, r300_demo now have headers for both vertex shader and pixel shader. Lastly, I think it would be useful to have an assembler for vertex shaders and pixel shaders that does the job similar to those DirectX functions that translate textual description into coded on (I also believe that OpenGL 2.0 should have something like this as well). What are your thoughts about this ? thank you ! 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
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: [R300] pixel shader
On Sunday 19 September 2004 03:53, Vladimir Dergachev wrote: Hi Nicolai, I committed a modification of pretty_print_command_stream.tcl that decodes most of PFS_INSTR* registers. It still prints the actual value written - as a last value after equals sign. So, I am hoping that even if this messed up your disassembler it is easy to fix - I am not that proficient in Python to venture modifying your code :) Also, r300_demo now have headers for both vertex shader and pixel shader. It did mess up the disassembler which uses a simple regex to catch the data, but it's an easy fix. Lastly, I think it would be useful to have an assembler for vertex shaders and pixel shaders that does the job similar to those DirectX functions that translate textual description into coded on (I also believe that OpenGL 2.0 should have something like this as well). Doesn't Mesa already support ARB_vertex_program and ARB_fragment_program? I think it would be best to add R300 programs as an additional backend for the already existing infrastructure, though I have no idea how flexible the existing code is - I haven't looked at it in detail. cu, Nicolai pgpPA5WoUzFsG.pgp Description: PGP signature
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: [R300] pixel shader
Lastly, I think it would be useful to have an assembler for vertex shaders and pixel shaders that does the job similar to those DirectX functions that translate textual description into coded on (I also believe that OpenGL 2.0 should have something like this as well). Doesn't Mesa already support ARB_vertex_program and ARB_fragment_program? I think it would be best to add R300 programs as an additional backend for the already existing infrastructure, though I have no idea how flexible the existing code is - I haven't looked at it in detail. Yes, you are correct ! I did not know this was implemented already. Does anyone on the list has any advice on how to use it ? thank you ! Vladimir Dergachev cu, Nicolai --- 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
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 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
