[Bug 13683] Internal Laptopdisplay blurrys to white screen after enabling modesetting on Radeon X700 Mobility
http://bugzilla.kernel.org/show_bug.cgi?id=13683 --- Comment #29 from Alex Deucher 2009-11-30 07:28:09 --- Created an attachment (id=23974) --> (http://bugzilla.kernel.org/attachment.cgi?id=23974) grab misc mode info for lvds Does this patch help? -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms/atom: pull misc mode info for lvds from bios tables
>From 0d49d381d6749dc3013527b369c83ef31852ce4c Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Mon, 30 Nov 2009 01:40:24 -0500 Subject: [PATCH] drm/radeon/kms/atom: pull misc mode info for lvds from bios tables sync polarity, etc. This will likely fix LVDS problems on some laptops. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_atombios.c | 15 ++- 1 files changed, 14 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index f0e8e60..604e1cd 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -912,7 +912,7 @@ struct radeon_encoder_atom_dig *radeon_atombios_get_lvds_info(struct struct radeon_device *rdev = dev->dev_private; struct radeon_mode_info *mode_info = &rdev->mode_info; int index = GetIndexIntoMasterTable(DATA, LVDS_Info); - uint16_t data_offset; + uint16_t data_offset, misc; union lvds_info *lvds_info; uint8_t frev, crev; struct radeon_encoder_atom_dig *lvds = NULL; @@ -951,6 +951,19 @@ struct radeon_encoder_atom_dig *radeon_atombios_get_lvds_info(struct lvds->panel_pwr_delay = le16_to_cpu(lvds_info->info.usOffDelayInMs); lvds->lvds_misc = lvds_info->info.ucLVDS_Misc; + + misc = le16_to_cpu(lvds_info->info.sLCDTiming.susModeMiscInfo.usAccess); + if (misc & ATOM_VSYNC_POLARITY) + lvds->native_mode.flags |= DRM_MODE_FLAG_NVSYNC; + if (misc & ATOM_HSYNC_POLARITY) + lvds->native_mode.flags |= DRM_MODE_FLAG_NHSYNC; + if (misc & ATOM_COMPOSITESYNC) + lvds->native_mode.flags |= DRM_MODE_FLAG_CSYNC; + if (misc & ATOM_INTERLACE) + lvds->native_mode.flags |= DRM_MODE_FLAG_INTERLACE; + if (misc & ATOM_DOUBLE_CLOCK_MODE) + lvds->native_mode.flags |= DRM_MODE_FLAG_DBLSCAN; + /* set crtc values */ drm_mode_set_crtcinfo(&lvds->native_mode, CRTC_INTERLACE_HALVE_V); -- 1.5.6.3 From 0d49d381d6749dc3013527b369c83ef31852ce4c Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Mon, 30 Nov 2009 01:40:24 -0500 Subject: [PATCH] drm/radeon/kms/atom: pull misc mode info for lvds from bios tables sync polarity, etc. This will likely fix LVDS problems on some laptops. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_atombios.c | 15 ++- 1 files changed, 14 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index f0e8e60..604e1cd 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -912,7 +912,7 @@ struct radeon_encoder_atom_dig *radeon_atombios_get_lvds_info(struct struct radeon_device *rdev = dev->dev_private; struct radeon_mode_info *mode_info = &rdev->mode_info; int index = GetIndexIntoMasterTable(DATA, LVDS_Info); - uint16_t data_offset; + uint16_t data_offset, misc; union lvds_info *lvds_info; uint8_t frev, crev; struct radeon_encoder_atom_dig *lvds = NULL; @@ -951,6 +951,19 @@ struct radeon_encoder_atom_dig *radeon_atombios_get_lvds_info(struct lvds->panel_pwr_delay = le16_to_cpu(lvds_info->info.usOffDelayInMs); lvds->lvds_misc = lvds_info->info.ucLVDS_Misc; + + misc = le16_to_cpu(lvds_info->info.sLCDTiming.susModeMiscInfo.usAccess); + if (misc & ATOM_VSYNC_POLARITY) + lvds->native_mode.flags |= DRM_MODE_FLAG_NVSYNC; + if (misc & ATOM_HSYNC_POLARITY) + lvds->native_mode.flags |= DRM_MODE_FLAG_NHSYNC; + if (misc & ATOM_COMPOSITESYNC) + lvds->native_mode.flags |= DRM_MODE_FLAG_CSYNC; + if (misc & ATOM_INTERLACE) + lvds->native_mode.flags |= DRM_MODE_FLAG_INTERLACE; + if (misc & ATOM_DOUBLE_CLOCK_MODE) + lvds->native_mode.flags |= DRM_MODE_FLAG_DBLSCAN; + /* set crtc values */ drm_mode_set_crtcinfo(&lvds->native_mode, CRTC_INTERLACE_HALVE_V); -- 1.5.6.3 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 19:51:55 Robert Noland wrote: > On Sun, 2009-11-29 at 15:36 -0800, vehemens wrote: > > I believe that moving away from the current model makes it more > > difficult > > to "... spread the burden ...", hence my objections. If you want to > > call > > that ranting or complaining, so be it. > > We no longer get to share the burden with the much larger group of linux > devs directly. That *was* my primary objection to > reorganizing/abandoning drm git in the first place. Yes, I'm a little > bitter about it when I have to recite how we got where we are, but it's > done, we lost, move on. > > As for the FreeBSD code, generally each subsystem has one primary > responsible individual. For drm, that person is me. Anyone is more > than welcome to submit patches for review by either sending them to the > mailing lists, sending them to me, or filing a PR. I've accepted > patches from you in the past and I will continue to do so, if you choose > to send them. > > At last check, you had not yet been granted commit privileges for drm > git, so your path was still to submit patches to the mailing list, or > directly to me. So, I don't quite get how it makes a difference to you > if you submit patches based on drm git or against the FreeBSD src tree. > For anyone to grant you commit privs, either on fd.o or FreeBSD.org (or > most any other repo for that matter) you are going to have to > demonstrate a track record of submitting reasonable patches and a > willingness to work and get along within that community of developers. > It has been more than a year since you submitted anything to me that was > coherent and usable. This tar file that you sent me is dated 09/12/09, > but despite your arguments, it isn't currently in a form that makes it > reasonable to extract the good changes from the bad. I look at diffs > pretty much every day. Robert it no longer matters. I'm going to concide defeat and switch to Linux. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25354] Blender crashes on startup on Radeon 7500 (and 9000-9200)
http://bugs.freedesktop.org/show_bug.cgi?id=25354 --- Comment #5 from Geir Ove Myhr 2009-11-29 20:13:57 PST --- (In reply to comment #4) > gpu_draw.c:1298 line contains following call: > glMatrixMode(GL_TEXTURE); The current SVN version of the file gpu_draw.c is available at https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/gpu/intern/gpu_draw.c -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25354] Blender crashes on startup on Radeon 7500 (and 9000-9200)
http://bugs.freedesktop.org/show_bug.cgi?id=25354 --- Comment #4 from Geir Ove Myhr 2009-11-29 20:04:40 PST --- Here is a backtrace obtained by Sami Pelkonen on T41 laptop with ATI Radeon Mobility 9000 (M9) Lf (AGP). Compiz disabled and glxgears also works. Compiled Blender SVN version (24195) with debugging and it produces following backtrace in gdb: Program received signal SIGSEGV, Segmentation fault. 0x00dfff8d in ?? () from /lib/ld-linux.so.2 (gdb) bt #0 0x00dfff8d in ?? () from /lib/ld-linux.so.2 #1 0x00e04326 in ?? () from /lib/ld-linux.so.2 #2 0x00e09fc0 in ?? () from /lib/ld-linux.so.2 #3 0x08713e75 in GPU_state_init () at source/blender/gpu/intern/gpu_draw.c:1298 #4 0x083e150a in wm_window_add_ghostwindow (wm=0xa0f01a8, title=0x93fd0c7 "Blender", win=0xa0f0278) at source/blender/windowmanager/intern/wm_window.c:332 #5 0x083e15df in wm_window_add_ghostwindows (wm=0xa0f01a8) at source/blender/windowmanager/intern/wm_window.c:371 #6 0x083e096e in wm_check (C=0x9dfbb78) at source/blender/windowmanager/intern/wm.c:218 #7 0x083df566 in WM_read_homefile (C=0x9dfbb78, op=0x0) at source/blender/windowmanager/intern/wm_files.c:325 #8 0x083ea58f in WM_init (C=0x9dfbb78) at source/blender/windowmanager/intern/wm_init_exit.c:130 #9 0x083ddd7b in main (argc=1, argv=0xb4e4) at source/creator/creator.c:498 gpu_draw.c:1298 line contains following call: glMatrixMode(GL_TEXTURE); -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25354] Blender crashes on startup on Radeon 7500 (and 9000-9200)
http://bugs.freedesktop.org/show_bug.cgi?id=25354 --- Comment #3 from Geir Ove Myhr 2009-11-29 20:00:13 PST --- Created an attachment (id=31570) --> (http://bugs.freedesktop.org/attachment.cgi?id=31570) glxinfo.txt -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25354] Blender crashes on startup on Radeon 7500 (and 9000-9200)
http://bugs.freedesktop.org/show_bug.cgi?id=25354 --- Comment #2 from Geir Ove Myhr 2009-11-29 19:59:46 PST --- Created an attachment (id=31569) --> (http://bugs.freedesktop.org/attachment.cgi?id=31569) lspci -vvnn -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25354] Blender crashes on startup on Radeon 7500 (and 9000-9200)
http://bugs.freedesktop.org/show_bug.cgi?id=25354 --- Comment #1 from Geir Ove Myhr 2009-11-29 19:59:17 PST --- Created an attachment (id=31568) --> (http://bugs.freedesktop.org/attachment.cgi?id=31568) Xorg.0.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25354] New: Blender crashes on startup on Radeon 7500 (and 9000-9200)
http://bugs.freedesktop.org/show_bug.cgi?id=25354 Summary: Blender crashes on startup on Radeon 7500 (and 9000- 9200) Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: gom...@gmail.com Reporting on behalf of ubuntu user mistr, based on comments on Launchpad bug: https://bugs.launchpad.net/bugs/446632 [Summary] Blender crashes in GPU_state_init() on startup on a computer with Radeon Mobility 7500. The same is reported on Radeon Mobility 9000 (M9) and Radeon 9200 by other users. The crash is on line 1298 in recent blender SVN, which contains the call: glMatrixMode(GL_TEXTURE); [How to reproduce] Start blender. Crash reported on official 32bit releases of 2.48a, 2.49, 2.49a, Ubuntu version (2.49a), 2.50 alpha0 and SVN 24195. A[ffected mesa versions] Crashes with mesa 7.6.0 which is currently in Ubuntu Karmic, and also with 7.7.0~git20091125+mesa-7-7-branch.7fac8ce7-0ubuntu0tormod from the ubuntu xorg-edgers repository. Downgrading to the git snapshot 7.6.0~git20090817.7c422387 that Ubuntu carried until 7.6.0 was released stops the crashes. mistr has said he is willing to git-bisect between 7.6.0~git20090817.7c422387 and 7.6.0, but he has not done it before and needs to figure out the details for how to do it in practice. [Chipset] 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] [1002:4c57] Subsystem: Compaq Computer Corporation Device [0e11:00b7] [Other system information] Architecture: i386 DistroRelease: Ubuntu 9.10 Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub MachineType: Compaq Evo N610c (DD502A#AK8) Package: mesa (not installed) PccardctlIdent: Socket 0: no product info available Socket 1: no product info available PccardctlStatus: Socket 0: 3.3V 32-bit PC Card Socket 1: no card ProcCmdLine: root=UUID=394fbc0f-c812-4c3b-b10a-445391ec9917 ro quiet splash ProcEnviron: SHELL=/bin/bash LANG=de_DE.UTF-8 ProcVersionSignature: Ubuntu 2.6.31-15.50-generic RelatedPackageVersions: xserver-xorg 1:7.4+3ubuntu7 libgl1-mesa-glx 7.7.0~git20091128+mesa-7-7-branch.e5159996-0ubuntu0tormod libdrm2 2.4.15+git20091125.6f66de98-0ubuntu0tormod~karmic xserver-xorg-video-intel 2:2.9.0+git20091125.917f9bb2-0ubuntu0tormod~karmic xserver-xorg-video-ati 1:6.12.99+git20091127.a8dbf7c2-0ubuntu0tormod~karmic Uname: Linux 2.6.31-15-generic i686 UserGroups: adm admin cdrom dialout dip lpadmin plugdev sambashare XsessionErrors: (gnome-settings-daemon:2250): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed (gnome-settings-daemon:2250): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed (nautilus:2283): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed (polkit-gnome-authentication-agent-1:2314): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed dmi.bios.date: 05/24/2003 dmi.bios.vendor: Compaq dmi.bios.version: 68P4F v2.49 F.14 dmi.board.name: 07F4 dmi.board.vendor: Compaq dmi.board.version: KBC Version . dmi.chassis.asset.tag: CNU33406WF dmi.chassis.type: 10 dmi.chassis.vendor: Compaq dmi.modalias: dmi:bvnCompaq:bvr68P4Fv2.49F.14:bd05/24/2003:svnCompaq:pnEvoN610c(DD502A#AK8):pvr:rvnCompaq:rn07F4:rvrKBCVersion.:cvnCompaq:ct10:cvr: dmi.product.name: Evo N610c (DD502A#AK8) dmi.sys.vendor: Compaq fglrx: Not loaded system: distro: Ubuntu architecture: i686kernel: 2.6.31-15-generic -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-29 at 15:36 -0800, vehemens wrote: > I believe that moving away from the current model makes it more > difficult > to "... spread the burden ...", hence my objections. If you want to > call > that ranting or complaining, so be it. We no longer get to share the burden with the much larger group of linux devs directly. That *was* my primary objection to reorganizing/abandoning drm git in the first place. Yes, I'm a little bitter about it when I have to recite how we got where we are, but it's done, we lost, move on. As for the FreeBSD code, generally each subsystem has one primary responsible individual. For drm, that person is me. Anyone is more than welcome to submit patches for review by either sending them to the mailing lists, sending them to me, or filing a PR. I've accepted patches from you in the past and I will continue to do so, if you choose to send them. At last check, you had not yet been granted commit privileges for drm git, so your path was still to submit patches to the mailing list, or directly to me. So, I don't quite get how it makes a difference to you if you submit patches based on drm git or against the FreeBSD src tree. For anyone to grant you commit privs, either on fd.o or FreeBSD.org (or most any other repo for that matter) you are going to have to demonstrate a track record of submitting reasonable patches and a willingness to work and get along within that community of developers. It has been more than a year since you submitted anything to me that was coherent and usable. This tar file that you sent me is dated 09/12/09, but despite your arguments, it isn't currently in a form that makes it reasonable to extract the good changes from the bad. I look at diffs pretty much every day. robert. -- Robert Noland 2Hip Networks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 29, 2009 at 5:03 PM, vehemens wrote: > On Sunday 29 November 2009 15:36:51 Adam K Kirchhoff wrote: >> On Sunday 29 November 2009 18:54:31 vehemens wrote: >> > On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote: >> > > On Sunday 29 November 2009 14:16:13 vehemens wrote: >> > > >> > > [snip] >> > > >> > > > Your missing the point of using a development structure which >> > > > supports collobration. >> > > >> > > [snip] >> > > >> > > > The difference is that you are the only one doing the work now. >> > > >> > > [snip] >> > > >> > > > Again, your missing the point of using a development structure which >> > > > supports collobration. >> > > >> > > [snip] >> > > >> > > > It hasn't moved "... well beyond what was in drm git." If you >> > > > believe otherwise, your only fooling yourself. >> > > >> > > [snip] >> > > >> > > > See above comments. >> > > >> > > Yes, you have made it abundantly clear that you are in favor of having >> > > a centralized repository for all DRM development. The fact is, that's >> > > not happening now and is not going to happen. That used to be the >> > > case, but the linux DRM developers did not see an advantage to that for >> > > themselves, and though rnoland was unhappy with the decision (because >> > > it made his job harder), the linux DRM developers did what they felt >> > > was best. >> > >> > You assuming what what good for Linux for a developer, is also good for a >> > BSD developer. As for making rnoland's job harder, it was his choice. >> >> Nice try, but I am making no such assumptions. It was not rnoland's choice >> to stop having the linux DRM developers stop using a centralized repository >> for all DRM code. He was quite clearly opposed to it and did not consider >> it a good choice. > > You missing the point as is rnoland. Just because the linux DRM developers > stopped using a centralized repository, didn't mean FreeBSD shouldn't as the > intial integration work would be still shared reducing the burden on any one > person. The approach taken by rnoland however was to shift all the work to > himself. Sorry to stick myself into this conversation, but isn't the freebsd tree now your centralized repository? Can't you just clone that and continue as before? -- Dan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 29, 2009 at 05:03:51PM -0800, vehemens wrote: > You missing the point as is rnoland. Just because the linux DRM developers > stopped using a centralized repository, didn't mean FreeBSD shouldn't as the > intial integration work would be still shared reducing the burden on any one > person. The approach taken by rnoland however was to shift all the work to > himself. Is it genuinely necessary to reply to every single mail in this thread, repeating the exact same thing over and over, ad nauseum? pgpsoaYovYUlS.pgp Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 15:36:51 Adam K Kirchhoff wrote: > On Sunday 29 November 2009 18:54:31 vehemens wrote: > > On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote: > > > On Sunday 29 November 2009 14:16:13 vehemens wrote: > > > > > > [snip] > > > > > > > Your missing the point of using a development structure which > > > > supports collobration. > > > > > > [snip] > > > > > > > The difference is that you are the only one doing the work now. > > > > > > [snip] > > > > > > > Again, your missing the point of using a development structure which > > > > supports collobration. > > > > > > [snip] > > > > > > > It hasn't moved "... well beyond what was in drm git." If you > > > > believe otherwise, your only fooling yourself. > > > > > > [snip] > > > > > > > See above comments. > > > > > > Yes, you have made it abundantly clear that you are in favor of having > > > a centralized repository for all DRM development. The fact is, that's > > > not happening now and is not going to happen. That used to be the > > > case, but the linux DRM developers did not see an advantage to that for > > > themselves, and though rnoland was unhappy with the decision (because > > > it made his job harder), the linux DRM developers did what they felt > > > was best. > > > > You assuming what what good for Linux for a developer, is also good for a > > BSD developer. As for making rnoland's job harder, it was his choice. > > Nice try, but I am making no such assumptions. It was not rnoland's choice > to stop having the linux DRM developers stop using a centralized repository > for all DRM code. He was quite clearly opposed to it and did not consider > it a good choice. You missing the point as is rnoland. Just because the linux DRM developers stopped using a centralized repository, didn't mean FreeBSD shouldn't as the intial integration work would be still shared reducing the burden on any one person. The approach taken by rnoland however was to shift all the work to himself. > > > Since then, rnoland has made significant progress porting the linux > > > specific changes over to FreeBSD. If you don't believe the changes > > > he's made in the FreeBSD source tree go 'well beyond' what had been in > > > mesa/drm on freedesktop git then you are fooling yourself. Frankly, if > > > I were Robert, I would be offended by that statement you made. > > > > I've diffed the code. Suggest that you do the same and see if you can > > still make the same statements. > > r6xx/r7xx DRM code, alone, pushes FreeBSD DRM "well beyond" what was in > mesa/drm on freedesktop. As for FreeBSD r6xx/r7xx DRM, here's an email on the subject which is how I remember the events. http://lists.freebsd.org/pipermail/freebsd-x11/2009-February/007624.html -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 18:54:31 vehemens wrote: > On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote: > > On Sunday 29 November 2009 14:16:13 vehemens wrote: > > > > [snip] > > > > > Your missing the point of using a development structure which supports > > > collobration. > > > > [snip] > > > > > The difference is that you are the only one doing the work now. > > > > [snip] > > > > > Again, your missing the point of using a development structure which > > > supports collobration. > > > > [snip] > > > > > It hasn't moved "... well beyond what was in drm git." If you believe > > > otherwise, your only fooling yourself. > > > > [snip] > > > > > See above comments. > > > > Yes, you have made it abundantly clear that you are in favor of having a > > centralized repository for all DRM development. The fact is, that's not > > happening now and is not going to happen. That used to be the case, but > > the linux DRM developers did not see an advantage to that for themselves, > > and though rnoland was unhappy with the decision (because it made his job > > harder), the linux DRM developers did what they felt was best. > > You assuming what what good for Linux for a developer, is also good for a > BSD developer. As for making rnoland's job harder, it was his choice. Nice try, but I am making no such assumptions. It was not rnoland's choice to stop having the linux DRM developers stop using a centralized repository for all DRM code. He was quite clearly opposed to it and did not consider it a good choice. > > Since then, rnoland has made significant progress porting the linux > > specific changes over to FreeBSD. If you don't believe the changes he's > > made in the FreeBSD source tree go 'well beyond' what had been in > > mesa/drm on freedesktop git then you are fooling yourself. Frankly, if I > > were Robert, I would be offended by that statement you made. > > I've diffed the code. Suggest that you do the same and see if you can > still make the same statements. r6xx/r7xx DRM code, alone, pushes FreeBSD DRM "well beyond" what was in mesa/drm on freedesktop. > > As has been said time and again, the kernel specific code in mesa/drm > > serves no purpose other than providing a historical log of the DRM > > development from that time, so there was no harm in pulling it. The > > FreeBSD DRM code follows the same development model as the rest of > > FreeBSD, and I have a hard time believing that such a model doesn't > > support collaboration. That is certainly an accusation I've never once > > heard made against the FreeBSD project in recent years till just now. > > If one stashes his/her development code where few if any can get at it, I > don't consider that collaboration. Many developers have private source repos for their code and only make such code available when it's actually usable for testing or further development by others. > > Now, the changes are made, and what's done is done. Can we please just > > move on? > > I was going to move along, but I felt your email had so many errors, I > couldn't let it got by. Nice try baiting me. I've said my two cents worth, and I'm done with this discussion. Adam -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote: > On Sunday 29 November 2009 14:16:13 vehemens wrote: > > [snip] > > > Your missing the point of using a development structure which supports > > collobration. > > [snip] > > > The difference is that you are the only one doing the work now. > > [snip] > > > Again, your missing the point of using a development structure which > > supports collobration. > > [snip] > > > It hasn't moved "... well beyond what was in drm git." If you believe > > otherwise, your only fooling yourself. > > [snip] > > > See above comments. > > Yes, you have made it abundantly clear that you are in favor of having a > centralized repository for all DRM development. The fact is, that's not > happening now and is not going to happen. That used to be the case, but > the linux DRM developers did not see an advantage to that for themselves, > and though rnoland was unhappy with the decision (because it made his job > harder), the linux DRM developers did what they felt was best. You assuming what what good for Linux for a developer, is also good for a BSD developer. As for making rnoland's job harder, it was his choice. > Since then, rnoland has made significant progress porting the linux > specific changes over to FreeBSD. If you don't believe the changes he's > made in the FreeBSD source tree go 'well beyond' what had been in mesa/drm > on freedesktop git then you are fooling yourself. Frankly, if I were > Robert, I would be offended by that statement you made. I've diffed the code. Suggest that you do the same and see if you can still make the same statements. > As has been said time and again, the kernel specific code in mesa/drm > serves no purpose other than providing a historical log of the DRM > development from that time, so there was no harm in pulling it. The > FreeBSD DRM code follows the same development model as the rest of FreeBSD, > and I have a hard time believing that such a model doesn't support > collaboration. That is certainly an accusation I've never once heard made > against the FreeBSD project in recent years till just now. If one stashes his/her development code where few if any can get at it, I don't consider that collaboration. > Now, the changes are made, and what's done is done. Can we please just > move on? I was going to move along, but I felt your email had so many errors, I couldn't let it got by. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 14:16:13 vehemens wrote: [snip] > Your missing the point of using a development structure which supports > collobration. [snip] > The difference is that you are the only one doing the work now. [snip] > Again, your missing the point of using a development structure which > supports collobration. [snip] > > It hasn't moved "... well beyond what was in drm git." If you believe > otherwise, your only fooling yourself. [snip] > See above comments. Yes, you have made it abundantly clear that you are in favor of having a centralized repository for all DRM development. The fact is, that's not happening now and is not going to happen. That used to be the case, but the linux DRM developers did not see an advantage to that for themselves, and though rnoland was unhappy with the decision (because it made his job harder), the linux DRM developers did what they felt was best. Since then, rnoland has made significant progress porting the linux specific changes over to FreeBSD. If you don't believe the changes he's made in the FreeBSD source tree go 'well beyond' what had been in mesa/drm on freedesktop git then you are fooling yourself. Frankly, if I were Robert, I would be offended by that statement you made. As has been said time and again, the kernel specific code in mesa/drm serves no purpose other than providing a historical log of the DRM development from that time, so there was no harm in pulling it. The FreeBSD DRM code follows the same development model as the rest of FreeBSD, and I have a hard time believing that such a model doesn't support collaboration. That is certainly an accusation I've never once heard made against the FreeBSD project in recent years till just now. Now, the changes are made, and what's done is done. Can we please just move on? Adam -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 10:39:34 Maarten Maathuis wrote: > I enjoy playing the devils advocate occasionally, so take this with a > grain of salt. > > My understanding is that there are roughly 3 bsd kernels that support > drm userspace interface(free*, open* and netbsd?), each has 1 or 2 > maintainers. For better or worse the linux guys/girls have gone their > own way. > > As far as i can tell kernel driver complexity has gone up in recent > time, to the point where nouveau (which is a relatively small group of > people too) has done the same (=move to a linux kernel tree) to avoid > the significant burden of backporting. Unless the 3 bsd kernels are > very similar i do not see how you expect to keep up. > > Instead of ranting you should ask yourself if it is even possible to > unify the drm code for all forms of bsd. Accept that the majority of > developers (which use linux as far as i know) have moved away from the > development model that you prefer. As the devils advocate i can say > that the gain for linux-drm from bsd-drm is not worth the effort of > the old development model, you are (unfortunately) forced to do more > work. > > Robert has accepted the reality, all you can try to do is spread the > burden across all the bsd's. The way you're being treated is a result > from the harsh reality that stems from the stalemate that the previous > development model caused. No amount of complaining is going to change > the fact that some people don't care about bsd. I believe that moving away from the current model makes it more difficult to "... spread the burden ...", hence my objections. If you want to call that ranting or complaining, so be it. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25346] kwin extraneous transparent boxes
http://bugs.freedesktop.org/show_bug.cgi?id=25346 --- Comment #1 from Aidan Marks 2009-11-29 13:09:28 PST --- Created an attachment (id=31557) --> (http://bugs.freedesktop.org/attachment.cgi?id=31557) kwin_extraneous_example2 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25346] New: kwin extraneous transparent boxes
http://bugs.freedesktop.org/show_bug.cgi?id=25346 Summary: kwin extraneous transparent boxes Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: ai...@cisco.com Created an attachment (id=31556) --> (http://bugs.freedesktop.org/attachment.cgi?id=31556) kwin_extraneous_example1 git libdrm/mesa/ddx with rv790. extraneous transparent boxes under kwin gl are seen to the left of the object and at the bottom right. also visible elsewhere, such as on the active application tabs on the kde taskbar. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
I enjoy playing the devils advocate occasionally, so take this with a grain of salt. My understanding is that there are roughly 3 bsd kernels that support drm userspace interface(free*, open* and netbsd?), each has 1 or 2 maintainers. For better or worse the linux guys/girls have gone their own way. As far as i can tell kernel driver complexity has gone up in recent time, to the point where nouveau (which is a relatively small group of people too) has done the same (=move to a linux kernel tree) to avoid the significant burden of backporting. Unless the 3 bsd kernels are very similar i do not see how you expect to keep up. Instead of ranting you should ask yourself if it is even possible to unify the drm code for all forms of bsd. Accept that the majority of developers (which use linux as far as i know) have moved away from the development model that you prefer. As the devils advocate i can say that the gain for linux-drm from bsd-drm is not worth the effort of the old development model, you are (unfortunately) forced to do more work. Robert has accepted the reality, all you can try to do is spread the burden across all the bsd's. The way you're being treated is a result from the harsh reality that stems from the stalemate that the previous development model caused. No amount of complaining is going to change the fact that some people don't care about bsd. Sincerely, Maarten Maathuis. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 07:07:41 Robert Noland wrote: > On Sat, 2009-11-28 at 20:40 -0800, vehemens wrote: > > On Saturday 28 November 2009 16:21:58 Robert Noland wrote: > > > On Sat, 2009-11-28 at 13:38 -0800, vehemens wrote: > > > > On Saturday 28 November 2009 10:41:39 Robert Noland wrote: > > > > > On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: > > > > > > On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: > > > > > > > On Sun, Nov 22, 2009 at 7:10 PM, vehemens > > > > > > > > > > > wrote: > > > > > > > > On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: > > > > > > > >> > I see that you deleted bsd-core dispite the requests of a > > > > > > > >> > number of people that you do not. > > > > > > > >> > > > > > > > >> Its git, nobody has touched any of it in ages, and none of > > > > > > > >> the BSD maintainers used it, you can just get it back by > > > > > > > >> branching from the commit before its removal, if you think > > > > > > > >> revival is needed, don't bring back linux-core when you do > > > > > > > >> please. > > > > > > > > > > > > > > > > I already told the both of you that I was planning to use it > > > > > > > > on IRC, I just haven't had time to put anything in. > > > > > > > > > > > > > > > > In addition, he's asking for a repro to libdrm. The way I > > > > > > > > see it, is there were two choices: > > > > > > > > 1) repro to libdrm, add the changes, not piss people off > > > > > > > > 2) add the changes, repro to libdrm, piss people off > > > > > > > > > > > > > > I think we pissed one person off, not people, as I said, there > > > > > > > are two people registered as BSD maintainers for drm code, oga > > > > > > > and rnoland, neither of them cared. I'm not sure what value the > > > > > > > codebase has if neither Free or OpenBSD are going to use it. > > > > > > > > > > > > You pissed a number of people off, but the difference with me is > > > > > > that I'm not letting either of you get away with it. > > > > > > > > > > > > There are more then two BSD maintainers, and your statement that > > > > > > neither of them cared is not correct. > > > > > > > > > > Don't get me wrong here, I don't like the current state of things, > > > > > but given current drm development practices, this change was > > > > > irrelevant. I was a bit frustrated at the build breakage for > > > > > libdrm, but krh and I worked through that and it is now resolved. > > > > > > > > > > While you have provided me with patches in the past, (which are > > > > > much appreciated) I have not seen consistent or relevant work > > > > > lately, so it really isn't clear to me how this is a big deal. > > > > > Given the nature of git, you could just branch your local repo > > > > > before that commit, though patches based on the old repo are > > > > > becoming increasingly difficult to merge into real code. > > > > > > > > I haven't published any of my work recently, but that doesn't mean I > > > > haven't done anything that I would like to share. Not sure why you > > > > feel this is important however. > > > > > > Because unpublished work doesn't exist That goes for the work that > > > I've done that isn't yet published as well. Until it is in the hands > > > of someone besides yourself it is irrelevant. > > > > Thats the whole point of having a public respository. How else can one > > publish? > > Again, there is nothing that prevents you from publishing your version > of the drm repo, though I don't see the point. Your missing the point of using a development structure which supports collobration. > > > > I gave you a number of suggestions in private emails on how to fix > > > > problems such as the merging issue and you were unwilling to take > > > > them. > > > > > > I'm not sure which issue you are referring to right now. But if you > > > mean trying to backport the work of Intel, ATI/AMD and nouveau into a > > > repository that all of the above have now abandoned, none who currently > > > have commit to the drm repo are willing or able to take on that task. > > > > > > Did you miss my plea's, rants and attempts to make valid arguments not > > > to reorganize/abandon drm in the first place? Unfortunately, we lost > > > that battle. It only served to increase the complexity and workload > > > that I am faced with. However, since every major vendor has now pulled > > > out and maintains a private linux repo for their code, the code that > > > lived in drm git was stale, and not terribly useful for anything other > > > than historical purposes. > > > > First you say abandoning the respository increased your workload, then > > you say it wasn't useful. Which is it? > > What increased my workload was having to go and try and pull changes > from several different linux trees and try to incorporate that into some > usable code base. Now, that the repo has been abandoned it is no longer > useful. If vendors were still committing to the repo, we wouldn't be > having this debate. > > > >
Re: RFC: libdrm repo
On Sunday 29 November 2009 00:31:17 Daniel Stone wrote: > Hi, > > On Sat, Nov 28, 2009 at 08:40:55PM -0800, vehemens wrote: > > On Saturday 28 November 2009 16:21:58 Robert Noland wrote: > > > Because unpublished work doesn't exist That goes for the work that > > > I've done that isn't yet published as well. Until it is in the hands > > > of someone besides yourself it is irrelevant. > > > > Thats the whole point of having a public respository. How else can one > > publish? > > gitorious, github, people.fd.o, freebsd.org public_html, etc, etc. Well I meant in the context of the existing structure, not starting a brand new one. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24611] KMS: Plugging in only S-video locks up machine
http://bugs.freedesktop.org/show_bug.cgi?id=24611 Pierre Ossman changed: What|Removed |Added Attachment #31547|0 |1 is obsolete|| --- Comment #15 from Pierre Ossman 2009-11-29 09:37:03 PST --- Created an attachment (id=31552) --> (http://bugs.freedesktop.org/attachment.cgi?id=31552) radeon-crtc-off.patch Walk the list from the DRM layer instead of hard-coding two CRTCs. This should make the code better prepared for the next gen with more CRTCs. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sat, 2009-11-28 at 20:40 -0800, vehemens wrote: > On Saturday 28 November 2009 16:21:58 Robert Noland wrote: > > On Sat, 2009-11-28 at 13:38 -0800, vehemens wrote: > > > On Saturday 28 November 2009 10:41:39 Robert Noland wrote: > > > > On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: > > > > > On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: > > > > > > On Sun, Nov 22, 2009 at 7:10 PM, vehemens > wrote: > > > > > > > On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: > > > > > > >> > I see that you deleted bsd-core dispite the requests of a > > > > > > >> > number of people that you do not. > > > > > > >> > > > > > > >> Its git, nobody has touched any of it in ages, and none of the > > > > > > >> BSD maintainers used it, you can just get it back by branching > > > > > > >> from the commit before its removal, if you think revival is > > > > > > >> needed, don't bring back linux-core when you do please. > > > > > > > > > > > > > > I already told the both of you that I was planning to use it on > > > > > > > IRC, I just haven't had time to put anything in. > > > > > > > > > > > > > > In addition, he's asking for a repro to libdrm. The way I see > > > > > > > it, is there were two choices: > > > > > > > 1) repro to libdrm, add the changes, not piss people off > > > > > > > 2) add the changes, repro to libdrm, piss people off > > > > > > > > > > > > I think we pissed one person off, not people, as I said, there are > > > > > > two people registered as BSD maintainers for drm code, oga and > > > > > > rnoland, neither of them cared. I'm not sure what value the > > > > > > codebase has if neither Free or OpenBSD are going to use it. > > > > > > > > > > You pissed a number of people off, but the difference with me is that > > > > > I'm not letting either of you get away with it. > > > > > > > > > > There are more then two BSD maintainers, and your statement that > > > > > neither of them cared is not correct. > > > > > > > > Don't get me wrong here, I don't like the current state of things, but > > > > given current drm development practices, this change was irrelevant. I > > > > was a bit frustrated at the build breakage for libdrm, but krh and I > > > > worked through that and it is now resolved. > > > > > > > > While you have provided me with patches in the past, (which are much > > > > appreciated) I have not seen consistent or relevant work lately, so it > > > > really isn't clear to me how this is a big deal. Given the nature of > > > > git, you could just branch your local repo before that commit, though > > > > patches based on the old repo are becoming increasingly difficult to > > > > merge into real code. > > > > > > I haven't published any of my work recently, but that doesn't mean I > > > haven't done anything that I would like to share. Not sure why you feel > > > this is important however. > > > > Because unpublished work doesn't exist That goes for the work that > > I've done that isn't yet published as well. Until it is in the hands of > > someone besides yourself it is irrelevant. > > Thats the whole point of having a public respository. How else can one > publish? Again, there is nothing that prevents you from publishing your version of the drm repo, though I don't see the point. > > > I gave you a number of suggestions in private emails on how to fix > > > problems such as the merging issue and you were unwilling to take them. > > > > I'm not sure which issue you are referring to right now. But if you > > mean trying to backport the work of Intel, ATI/AMD and nouveau into a > > repository that all of the above have now abandoned, none who currently > > have commit to the drm repo are willing or able to take on that task. > > > > Did you miss my plea's, rants and attempts to make valid arguments not > > to reorganize/abandon drm in the first place? Unfortunately, we lost > > that battle. It only served to increase the complexity and workload > > that I am faced with. However, since every major vendor has now pulled > > out and maintains a private linux repo for their code, the code that > > lived in drm git was stale, and not terribly useful for anything other > > than historical purposes. > > First you say abandoning the respository increased your workload, then you > say > it wasn't useful. Which is it? What increased my workload was having to go and try and pull changes from several different linux trees and try to incorporate that into some usable code base. Now, that the repo has been abandoned it is no longer useful. If vendors were still committing to the repo, we wouldn't be having this debate. > > If you are referring to the patches/diffs that you have sent me, then I > > have always appreciated the work that you have done. The last batch of > > stuff that you sent me, however was quite a mess. While there was some > > nice cleanup in it, it also contained at least some reversions of code > > specifically changed for FreeBSD. Even more of
[Bug 24611] KMS: Plugging in only S-video locks up machine
http://bugs.freedesktop.org/show_bug.cgi?id=24611 --- Comment #14 from Pierre Ossman 2009-11-29 03:26:03 PST --- Created an attachment (id=31547) --> (http://bugs.freedesktop.org/attachment.cgi?id=31547) radeon-crtc-off.patch More testing has narrowed it down to the requirement that it's the mode reconfiguration of the first CRTC that breaks something. agd5f seems to remember that UMS disables unused CRTCs before configuring the used one, the opposite of how KMS does it. This would explain why noone has complained about this bug until now. Doing the same in KMS is not that trivial though as it would mean reorganising the DRM layer. Instead, we can copy the code which disables all active CRTCs before each reconfiguration, and extend it to also disable the unused ones. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch VIA UniChrome DRM][2/3 Ver2] Add interfaces for communication with V4L and DDMPEG
brucech...@via.com.tw wrote:
> Hello Sirs:
> This patch is to add the interface to communicate with V4L and DDMPEG.
>
> Signed-off-by Bruce C. Chang
>
> diff -ruN old/drivers/gpu/drm/via/via_dma.c new/drivers/gpu/drm/via/via_dma.c
> --- old/drivers/gpu/drm/via/via_dma.c 2009-10-22 10:42:10.0 +0800
> +++ new/drivers/gpu/drm/via/via_dma.c 2009-10-22 12:48:26.0 +0800
> @@ -824,6 +824,7 @@
> DRM_IOCTL_DEF(DRM_VIA_FB_INIT, via_fb_init, DRM_AUTH|DRM_MASTER),
> DRM_IOCTL_DEF(DRM_VIA_MAP_INIT, via_map_init, DRM_AUTH|DRM_MASTER),
> DRM_IOCTL_DEF(DRM_VIA_DEC_FUTEX, via_decoder_futex, DRM_AUTH),
> + DRM_IOCTL_DEF(DRM_VIA_GET_INFO, via_get_drm_info, DRM_AUTH),
>
This is a backwards-compatible interface change, so please bump the
minor version number as well.
> DRM_IOCTL_DEF(DRM_VIA_DMA_INIT, via_dma_init, DRM_AUTH),
> DRM_IOCTL_DEF(DRM_VIA_CMDBUFFER, via_cmdbuffer, DRM_AUTH),
> DRM_IOCTL_DEF(DRM_VIA_FLUSH, via_flush_ioctl, DRM_AUTH),
> diff -ruN old/drivers/gpu/drm/via/via_drv.h new/drivers/gpu/drm/via/via_drv.h
> --- old/drivers/gpu/drm/via/via_drv.h 2009-10-22 10:42:10.0 +0800
> +++ new/drivers/gpu/drm/via/via_drv.h 2009-10-22 12:48:26.0 +0800
> @@ -121,6 +121,8 @@
> extern int via_agp_init(struct drm_device *dev, void *data, struct drm_file
> *file_priv);
> extern int via_map_init(struct drm_device *dev, void *data, struct drm_file
> *file_priv);
> extern int via_decoder_futex(struct drm_device *dev, void *data, struct
> drm_file *file_priv);
> +extern int via_get_drm_info(struct drm_device *dev, void *data,
> + struct drm_file *file_priv);
> extern int via_wait_irq(struct drm_device *dev, void *data, struct drm_file
> *file_priv);
> extern int via_dma_blit_sync( struct drm_device *dev, void *data, struct
> drm_file *file_priv );
> extern int via_dma_blit( struct drm_device *dev, void *data, struct drm_file
> *file_priv );
> diff -ruN old/drivers/gpu/drm/via/via_map.c new/drivers/gpu/drm/via/via_map.c
> --- old/drivers/gpu/drm/via/via_map.c 2009-10-22 10:42:10.0 +0800
> +++ new/drivers/gpu/drm/via/via_map.c 2009-10-22 12:48:26.0 +0800
> @@ -143,3 +143,21 @@
>
> return 0;
> }
> +
> +/* This function is for via another video decoder driver to get information
> */
> +int via_get_drm_info(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + drm_via_private_t *dev_priv = (drm_via_private_t *)dev->dev_private;
> + struct drm_via_info *info = data;
> +
> + if (!dev_priv->initialize || !dev->agp_buffer_map)
> + return -EINVAL;
> +
> + info->RegSize = dev_priv->mmio->size;
> + info->AgpSize = dev->agp_buffer_map->size;
> + info->RegHandle = dev_priv->mmio->offset;
> + info->AgpHandle = dev->agp_buffer_map->offset;
> +
> + return 0;
> +}
>
Please add a check to make sure the register map is exported read-only.
> diff -ruN old/drivers/gpu/drm/via/via_mm.c new/drivers/gpu/drm/via/via_mm.c
> --- old/drivers/gpu/drm/via/via_mm.c 2009-10-22 10:42:10.0 +0800
> +++ new/drivers/gpu/drm/via/via_mm.c 2009-10-22 12:48:26.0 +0800
> @@ -57,6 +57,8 @@
> DRM_DEBUG("offset = %u, size = %u\n", agp->offset, agp->size);
> return 0;
> }
> +static void *global_dev;
> +static void *global_file_priv;
>
Hmm.
This needs a callback to v4l to make sure v4l releases all its memory
when global_file_priv or global_dev goes away.
What may happen is that the X server shuts down, and then all memory
regions will be freed, but v4l may continue to use global_file_priv,
which doesn't exist anymore and cause a kernel oops.
>
> int via_fb_init(struct drm_device *dev, void *data, struct drm_file
> *file_priv)
> {
> @@ -79,6 +81,8 @@
>
> mutex_unlock(&dev->struct_mutex);
> DRM_DEBUG("offset = %u, size = %u\n", fb->offset, fb->size);
> + global_dev = dev;
> + global_file_priv = file_priv;
>
> return 0;
>
> @@ -291,3 +295,28 @@
> mutex_unlock(&dev->struct_mutex);
> return;
> }
> +
> +/* These two function is exported for via V4L module communication */
> +static int via_fb_alloc(drm_via_mem_t *mem)
> +{
> + struct drm_device *dev = global_dev;
> + struct drm_file *file_priv = global_file_priv;
> +
> + if (dev && file_priv)
> + return via_mem_alloc(dev, mem, file_priv);
> + else
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(via_fb_alloc);
> +
> +static int via_fb_free(drm_via_mem_t *mem)
> +{
> + struct drm_device *dev = global_dev;
> + struct drm_file *file_priv = global_file_priv;
> +
> + if (dev && file_priv)
> + return via_mem_free(dev, mem, file_priv);
> + else
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(via_fb_free);
> diff -ruN old/include/drm/via_drm.h new/include/drm/via_drm.h
> --- old/include/drm/via_drm.h 2009-10-22 10:42:10.0 +0800
> +++ new/include/drm/via_drm.h 2009-10-22 12:52:51.000
Re: [patch 1/5] drm/via: add pci id for VIA VX800 chipset
Dave Airlie wrote:
> On Wed, Nov 18, 2009 at 8:41 AM, wrote:
>
>> From: Thomas Schlichter
>>
>> The VIA DRM module is able to accelerate 2D video on the VX800 chipset,
>> thus add the corresponding PCI ID. Accelerated 3D video is not
>> implemented.
>>
>> The modified VIA DRM module was tested with X.Org openchrome driver on a
>> Samsung NC20 netbook. Video playback with xine requires nearly 30% less
>> CPU cycles.
>>
>
> I think this was an mtrr missing workaround,
>
> I think we dropped this in favour of fixing things properly, correct
> me if I'm wrong.
>
> Thomas?
>
>
Yes, this is being fixed elsewhere to have libpciaccess and kernel agree
in the case where PAT is not enabled.
So as long as e don't have any explicit VX800 support in DRM, I suggest
we leave this patch out.
/Thomas
> Dave.
>
>
>> Signed-off-by: Thomas Schlichter
>> Cc: Dave Airlie
>>
>
>
>> Cc: Eric Anholt
>> Signed-off-by: Andrew Morton
>> ---
>>
>> include/drm/drm_pciids.h |1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff -puN include/drm/drm_pciids.h~drm-via-add-pci-id-for-via-vx800-chipset
>> include/drm/drm_pciids.h
>> --- a/include/drm/drm_pciids.h~drm-via-add-pci-id-for-via-vx800-chipset
>> +++ a/include/drm/drm_pciids.h
>> @@ -477,6 +477,7 @@
>>{0x1106, 0x3343, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
>>{0x1106, 0x3230, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VIA_DX9_0}, \
>>{0x1106, 0x3157, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VIA_PRO_GROUP_A}, \
>> + {0x1106, 0x1122, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VIA_DX9_0}, \
>>{0, 0, 0}
>>
>> #define i810_PCI_IDS \
>> _
>>
>> --
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> --
>> ___
>> Dri-devel mailing list
>> Dri-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/dri-devel
>>
>>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch VIA UniChrome DRM][1/3 Ver2] Add support for ACPI suspend/resume.
brucech...@via.com.tw wrote:
> Hello Sirs:
> This patch is to add the support of ACPI suspend/resume. Some information
> locating in video memory
> need to be saved for 3D function. The mesa driver source has been release on
> VIA Linux portal
> (http://linux.via.com.tw/support/beginDownload.action?eleid=241&fid=463) last
> year although it's old.
>
Bruce, this patch still have some rough edges.
In principle, with the way the VIA drm module is made, it should really
be shut down by the X server before suspend / resume.
For example, there may be textures, video images and other stuff in VRAM
that require saving. As mentioned previously, the
X server should ideally handle this by mallocing a big area and saving
all the VRAM it has directed for DRM to manage. This may be a little
slow, but on the other hand, the memory will be swappable. I didn't
quite follow the reasons why you didn't want to use this approach.
In the patch below, ioremap() is used to map videoram, and kmalloc() is
used to get system memory. Both ioremap() address space and kmalloc()
memory of sizes > 4KiB is a scarce resource.
So,
a) I'd like to see a more thorough explanation why the X server saving
approach is not used.
b) Limit VIA_MEM_VIDEO_SAVE chunks to 4KiB each. That will make sure
kmalloc() is much less likely to fail.
c) Put an upper (rather small) limit of the amount of VIA_MEM_VIDEO_SAVE
memory to stop it from pinning all system memory, os use up all
ioremap() address space.
d) Please use the kernel linked list implementation. It makes the code
easier to follow.
/Thanks.
> Signed-off-by Bruce C. Chang
>
> diff -ruN old/drivers/gpu/drm/via/via_dma.c new/drivers/gpu/drm/via/via_dma.c
> --- old/drivers/gpu/drm/via/via_dma.c 2009-10-22 10:13:59.0 +0800
> +++ new/drivers/gpu/drm/via/via_dma.c 2009-10-22 10:22:11.0 +0800
> @@ -68,6 +68,8 @@
> *vb++ = (w2); \
> dev_priv->dma_low += 8;
>
> +static void via_cmdbuf_flush(struct drm_via_private *dev_priv,
> + uint32_t cmd_type);
> static void via_cmdbuf_start(drm_via_private_t * dev_priv);
> static void via_cmdbuf_pause(drm_via_private_t * dev_priv);
> static void via_cmdbuf_reset(drm_via_private_t * dev_priv);
> @@ -155,6 +157,11 @@
>
> int via_dma_cleanup(struct drm_device * dev)
> {
> + struct drm_via_video_save_head *pnode;
> +
> + for (pnode = via_video_save_head; pnode; pnode =
> + (struct drm_via_video_save_head *)pnode->next)
> + memcpy(pnode->psystemmem, pnode->pvideomem, pnode->size);
> if (dev->dev_private) {
> drm_via_private_t *dev_priv =
> (drm_via_private_t *) dev->dev_private;
> @@ -175,6 +182,7 @@
> drm_via_private_t * dev_priv,
> drm_via_dma_init_t * init)
> {
> + struct drm_via_video_save_head *pnode;
> if (!dev_priv || !dev_priv->mmio) {
> DRM_ERROR("via_dma_init called before via_map_init\n");
> return -EFAULT;
> @@ -195,6 +203,9 @@
> return -EINVAL;
> }
>
> + for (pnode = via_video_save_head; pnode; pnode = pnode->next)
> + memcpy(pnode->pvideomem, pnode->psystemmem, pnode->size);
> +
> dev_priv->ring.map.offset = dev->agp->base + init->offset;
> dev_priv->ring.map.size = init->size;
> dev_priv->ring.map.type = 0;
> @@ -737,6 +748,75 @@
> return ret;
> }
>
> +/* For acpi case, when system resume from suspend or hibernate,
> + * need to re-initialize dma info into HW
> + */
> +int via_drm_resume(struct drm_device *drm_dev)
> +{
> + struct pci_dev *pci = drm_dev->pdev;
> + drm_via_private_t *dev_priv =
> + (drm_via_private_t *) drm_dev->dev_private;
> + struct drm_via_video_save_head *pnode = 0;
> +
> + pci_set_power_state(pci, PCI_D0);
> + pci_restore_state(pci);
> + if (pci_enable_device(pci))
> + return -1;
> + if (!dev_priv->initialize)
> + return 0;
> +
> + /* here we need to restore some video memory content */
> + for (pnode = via_video_save_head; pnode; pnode = pnode->next)
> + memcpy(pnode->pvideomem, pnode->psystemmem, pnode->size);
> +
> + /* if pci path, return */
> + if (!dev_priv->ring.virtual_start)
> + return 0;
> +
> + dev_priv->dma_ptr = dev_priv->ring.virtual_start;
> + dev_priv->dma_low = 0;
> + dev_priv->dma_high = 0x100;
> + dev_priv->dma_wrap = 0x100;
> + dev_priv->dma_offset = 0x0;
> + dev_priv->last_pause_ptr = NULL;
> + dev_priv->hw_addr_ptr = dev_priv->mmio->handle + 0x418;
> +
> + via_cmdbuf_start(dev_priv);
> +
> + return 0;
> +}
> +
> +int via_drm_suspend(struct drm_device *drm_dev, pm_message_t state)
> +{
> + struct pci_dev *pci = drm_dev->pdev;
> + drm_via_private_t *dev_priv =
> + (drm_via_private_t *) drm_dev->dev_private;
> +
> + struct drm_via_video
Re: [Patch VIA UniChrome DRM][3/3 Ver2] Fix video hang issue caused by verification function
brucech...@via.com.tw wrote:
> Hello Sirs:
> This patch is to solve the video hang issue caused by verification
> function. These 3 patches has been verified in (1) CX700M platform (2) CLE266
> platform (3) K8M800 platform (4) CN400 platform with UniChrome/OpenChrome
> driver except few of these platform is not supported by UniChrome such as
> CX700 chipset.
>
> Signed-off-by Bruce C. Chang
>
> diff -ruN old/drivers/gpu/drm/via/via_3d_reg.h
> new/drivers/gpu/drm/via/via_3d_reg.h
> --- old/drivers/gpu/drm/via/via_3d_reg.h 2009-10-22 13:01:06.0
> +0800
> +++ new/drivers/gpu/drm/via/via_3d_reg.h 2009-10-22 13:11:31.0
> +0800
> @@ -1647,4 +1647,6 @@
> #define VIA_VIDEO_HEADER6 0xFE05
> #define VIA_VIDEO_HEADER7 0xFE06
> #define VIA_VIDEOMASK 0x
> +#define INV_DUMMY_MASK 0xFF00
> +#define HALCYON_HEADER_MASK 0xFE00
> #endif
> diff -ruN old/drivers/gpu/drm/via/via_verifier.c
> new/drivers/gpu/drm/via/via_verifier.c
> --- old/drivers/gpu/drm/via/via_verifier.c2009-10-22 13:01:06.0
> +0800
> +++ new/drivers/gpu/drm/via/via_verifier.c2009-10-22 13:05:49.0
> +0800
> @@ -227,7 +227,10 @@
> {0xf2, check_for_header2_err},
> {0xf0, check_for_header1_err},
> {0xcc, check_for_dummy},
> - {0x00, check_number_texunits}
> + {0x00, check_number_texunits},
> + {0x01, no_check},
> + {0x02, no_check},
> + {0x03, no_check}
> };
>
> static hazard_t table1[256];
> @@ -768,11 +771,12 @@
> DRM_ERROR("Invalid VIDEO DMA command. "
> "Attempt to access 3D- or command burst area.\n");
> return 1;
> - } else if ((address > 0xCFF) && (address < 0x1300)) {
> + } else if ((address > 0xDFF) && (address < 0x1200)) {
> DRM_ERROR("Invalid VIDEO DMA command. "
> "Attempt to access PCI DMA area.\n");
> return 1;
> - } else if (address > 0x13FF) {
> + } else if (((address > 0x13FF) && (address < 0x2200)) ||
> + (address > 0x33ff)) {
> DRM_ERROR("Invalid VIDEO DMA command. "
> "Attempt to access VGA registers.\n");
> return 1;
> @@ -791,10 +795,11 @@
> return 1;
> }
> while (dwords--) {
> - if (*buf++) {
> + if (*buf && !is_dummy_cmd(*buf)) {
> DRM_ERROR("Illegal video command tail.\n");
> return 1;
> }
> + buf++;
> }
> *buffer = buf;
> return 0;
> diff -ruN old/drivers/gpu/drm/via/via_verifier.h
> new/drivers/gpu/drm/via/via_verifier.h
> --- old/drivers/gpu/drm/via/via_verifier.h2009-10-22 13:01:06.0
> +0800
> +++ new/drivers/gpu/drm/via/via_verifier.h2009-10-22 13:05:49.0
> +0800
> @@ -25,7 +25,7 @@
>
> #ifndef _VIA_VERIFIER_H_
> #define _VIA_VERIFIER_H_
> -
> +#include "via_3d_reg.h"
> typedef enum {
> no_sequence = 0,
> z_address,
> @@ -59,4 +59,31 @@
> extern int via_parse_command_stream(struct drm_device *dev, const uint32_t
> *buf,
> unsigned int size);
>
> +static inline int is_agp_header(unsigned int data)
> +{
> + if (data == HALCYON_HEADER2)
> + return 1;
> + else if ((data & VIA_VIDEOMASK) == VIA_VIDEO_HEADER5)
> + ;
> + else if ((data & VIA_VIDEOMASK) == VIA_VIDEO_HEADER6)
> + ;
> + else if ((data & HALCYON_HEADER_MASK) == HALCYON_HEADER1)
> + ;
> + else
> + return 0;
> +
> + return 1;
> +}
> +
> +static inline int is_dummy_cmd(uint32_t cmd)
> +{
> + if ((cmd & INV_DUMMY_MASK) == 0xCC00 ||
> + (cmd & INV_DUMMY_MASK) == 0xCD00 ||
> + (cmd & INV_DUMMY_MASK) == 0xCE00 ||
> + (cmd & INV_DUMMY_MASK) == 0xCF00 ||
> + (cmd & INV_DUMMY_MASK) == 0xDD00)
> + return 1;
> + return 0;
> +}
> +
> #endif
>
> Thanks and Best Regards
> =
> Bruce C. Chang(張祖明)
> VIA Technologies, Inc.
> Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei
> Tel: +886-2-22185452 Ext 7323
> Mobile: +886-968343824
> Fax: +886-2-22186282
> Skype: Bruce.C.Chang
> Email: brucech...@via.com.tw
>
Acked-By: Thomas Hellstrom
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-d
Re: [patch] fix small memory leak in ttm_memory.c
Dan Carpenter wrote:
> I moved the allocation until after the check for (si->totalhigh == 0).
>
> regards,
> dan carpenter
>
> Signed-off-by: Dan Carpenter
>
> --- orig/drivers/gpu/drm/ttm/ttm_memory.c 2009-11-28 07:05:54.0
> +0200
> +++ devel/drivers/gpu/drm/ttm/ttm_memory.c2009-11-28 07:07:52.0
> +0200
> @@ -274,16 +274,17 @@ static int ttm_mem_init_kernel_zone(stru
> static int ttm_mem_init_highmem_zone(struct ttm_mem_global *glob,
>const struct sysinfo *si)
> {
> - struct ttm_mem_zone *zone = kzalloc(sizeof(*zone), GFP_KERNEL);
> + struct ttm_mem_zone *zone;
> uint64_t mem;
> int ret;
>
> - if (unlikely(!zone))
> - return -ENOMEM;
> -
> if (si->totalhigh == 0)
> return 0;
>
> + zone = kzalloc(sizeof(*zone), GFP_KERNEL);
> + if (unlikely(!zone))
> + return -ENOMEM;
> +
> mem = si->totalram;
> mem *= si->mem_unit;
>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
Acked-By: Thomas Hellstrom
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
Hi, On Sat, Nov 28, 2009 at 08:40:55PM -0800, vehemens wrote: > On Saturday 28 November 2009 16:21:58 Robert Noland wrote: > > Because unpublished work doesn't exist That goes for the work that > > I've done that isn't yet published as well. Until it is in the hands of > > someone besides yourself it is irrelevant. > > Thats the whole point of having a public respository. How else can one > publish? gitorious, github, people.fd.o, freebsd.org public_html, etc, etc. Cheers, Daniel pgpLz1f0MtR1U.pgp Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
