[Patch 2/4] drm: Remove the macro defintion of DRM_DEBUG_MODE
From: Zhao Yakui yakui.z...@intel.com
Two macro definitions of DRM_DEBUG_KMS/MODE can be used to add the debug
info related with KMS. It is confusing.
So remove the macro definition of DRM_DEBUG_MODE. Instead it can be replaced
by the DRM_DEBUG_KMS.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
Acked-by: Ian Romanick ian.d.roman...@intel.com
---
drivers/gpu/drm/drm_modes.c |4 ++--
include/drm/drmP.h |7 ---
2 files changed, 2 insertions(+), 9 deletions(-)
Index: linux-2.6/drivers/gpu/drm/drm_modes.c
===
--- linux-2.6.orig/drivers/gpu/drm/drm_modes.c 2009-07-16 13:53:38.0
+0800
+++ linux-2.6/drivers/gpu/drm/drm_modes.c 2009-07-16 14:03:57.0
+0800
@@ -50,7 +50,7 @@
*/
void drm_mode_debug_printmodeline(struct drm_display_mode *mode)
{
- DRM_DEBUG_MODE(Modeline %d:\%s\ %d %d %d %d %d %d %d %d %d %d
+ DRM_DEBUG_KMS(Modeline %d:\%s\ %d %d %d %d %d %d %d %d %d %d
0x%x 0x%x\n,
mode-base.id, mode-name, mode-vrefresh, mode-clock,
mode-hdisplay, mode-hsync_start,
@@ -402,7 +402,7 @@
list_del(mode-head);
if (verbose) {
drm_mode_debug_printmodeline(mode);
- DRM_DEBUG_MODE(Not using %s mode %d\n,
+ DRM_DEBUG_KMS(Not using %s mode %d\n,
mode-name, mode-status);
}
drm_mode_destroy(dev, mode);
Index: linux-2.6/include/drm/drmP.h
===
--- linux-2.6.orig/include/drm/drmP.h 2009-07-16 13:53:38.0 +0800
+++ linux-2.6/include/drm/drmP.h2009-07-16 14:04:44.0 +0800
@@ -88,7 +88,6 @@
#define DRM_UT_CORE0x01
#define DRM_UT_DRIVER 0x02
#define DRM_UT_KMS 0x04
-#define DRM_UT_MODE0x08
extern void drm_ut_debug_printk(unsigned int request_level,
const char *prefix,
@@ -184,11 +183,6 @@
drm_ut_debug_printk(DRM_UT_KMS, DRM_NAME, \
__func__, fmt, ##args);\
} while (0)
-#define DRM_DEBUG_MODE(fmt, args...) \
- do {\
- drm_ut_debug_printk(DRM_UT_MODE, DRM_NAME, \
-__func__, fmt, ##args);\
- } while (0)
#define DRM_LOG(fmt, args...) \
do {\
drm_ut_debug_printk(DRM_UT_CORE, NULL, \
@@ -212,7 +206,6 @@
#else
#define DRM_DEBUG_DRIVER(fmt, args...) do { } while (0)
#define DRM_DEBUG_KMS(fmt, args...)do { } while (0)
-#define DRM_DEBUG_MODE(fmt, args...) do { } while (0)
#define DRM_DEBUG(fmt, arg...) do { } while (0)
#define DRM_LOG(fmt, arg...) do { } while (0)
#define DRM_LOG_KMS(fmt, args...) do { } while (0)
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
Hello Jerome, Keith: It's hard to review if the interface is sane without knowing what userspace might need or not. Maybe VIA can provide some userspace code without putting together an entire driver. Can I suggest to verify the DRM source with the X driver which we will release within 1 month? 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 -Original Message- From: Jerome Glisse [mailto:gli...@freedesktop.org] Sent: Friday, July 17, 2009 8:44 PM To: Harald Welte Cc: Dave Airlie; Benjamin Pan (Fremont); Richard Lee; gre...@suse.de; Bruce Chang; Joseph Chan; dri-devel@lists.sourceforge.net Subject: Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream On Fri, 2009-07-17 at 13:37 +0200, Harald Welte wrote: [...] So far I was not aware that there is an absolute precondition of existing 3D FOSS userspace code to get a DRM driver merged. Yes, we all want it. But is it a strong requirement? It's hard to review if the interface is sane without knowing what userspace might need or not. Cheers, Jerome Glisse -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/4] DRM: Remove the unused prefix in DRM_DEBUG_KMS/DRIVER/MODE
From: Zhao Yakui yakui.z...@intel.com
We will have to add a prefix when using the macro defintion of DRM_DEBUG_KMS
/DRM_DEBUG_DRIVER/MODE. It is not convenient. We should use the DRM_NAME
as default prefix.
So remove the prefix in the macro definition of DRM_DEBUG_KMS/DRIVER/MODE.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
Acked-by: Ian Romanick ian.d.roman...@intel.com
---
drivers/gpu/drm/drm_modes.c |8 +++-
drivers/gpu/drm/i915/i915_dma.c | 35 +++
drivers/gpu/drm/i915/intel_lvds.c | 10 +++---
drivers/gpu/drm/i915/intel_sdvo.c | 31 ++-
include/drm/drmP.h| 18 +-
5 files changed, 44 insertions(+), 58 deletions(-)
Index: linux-2.6/include/drm/drmP.h
===
--- linux-2.6.orig/include/drm/drmP.h 2009-07-16 13:53:24.0 +0800
+++ linux-2.6/include/drm/drmP.h2009-07-16 13:53:38.0 +0800
@@ -174,19 +174,19 @@
__func__, fmt, ##args); \
} while (0)
-#define DRM_DEBUG_DRIVER(prefix, fmt, args...) \
+#define DRM_DEBUG_DRIVER(fmt, args...) \
do {\
- drm_ut_debug_printk(DRM_UT_DRIVER, prefix, \
+ drm_ut_debug_printk(DRM_UT_DRIVER, DRM_NAME,\
__func__, fmt, ##args); \
} while (0)
-#define DRM_DEBUG_KMS(prefix, fmt, args...)\
+#define DRM_DEBUG_KMS(fmt, args...)\
do {\
- drm_ut_debug_printk(DRM_UT_KMS, prefix, \
+ drm_ut_debug_printk(DRM_UT_KMS, DRM_NAME, \
__func__, fmt, ##args);\
} while (0)
-#define DRM_DEBUG_MODE(prefix, fmt, args...) \
+#define DRM_DEBUG_MODE(fmt, args...) \
do {\
- drm_ut_debug_printk(DRM_UT_MODE, prefix,\
+ drm_ut_debug_printk(DRM_UT_MODE, DRM_NAME, \
__func__, fmt, ##args);\
} while (0)
#define DRM_LOG(fmt, args...) \
@@ -210,9 +210,9 @@
NULL, fmt, ##args); \
} while (0)
#else
-#define DRM_DEBUG_DRIVER(prefix, fmt, args...) do { } while (0)
-#define DRM_DEBUG_KMS(prefix, fmt, args...)do { } while (0)
-#define DRM_DEBUG_MODE(prefix, fmt, args...) do { } while (0)
+#define DRM_DEBUG_DRIVER(fmt, args...) do { } while (0)
+#define DRM_DEBUG_KMS(fmt, args...)do { } while (0)
+#define DRM_DEBUG_MODE(fmt, args...) do { } while (0)
#define DRM_DEBUG(fmt, arg...) do { } while (0)
#define DRM_LOG(fmt, arg...) do { } while (0)
#define DRM_LOG_KMS(fmt, args...) do { } while (0)
Index: linux-2.6/drivers/gpu/drm/drm_modes.c
===
--- linux-2.6.orig/drivers/gpu/drm/drm_modes.c 2009-07-16 13:53:24.0
+0800
+++ linux-2.6/drivers/gpu/drm/drm_modes.c 2009-07-16 13:53:38.0
+0800
@@ -38,7 +38,6 @@
#include drm.h
#include drm_crtc.h
-#define DRM_MODESET_DEBUG drm_mode
/**
* drm_mode_debug_printmodeline - debug print a mode
* @dev: DRM device
@@ -51,8 +50,8 @@
*/
void drm_mode_debug_printmodeline(struct drm_display_mode *mode)
{
- DRM_DEBUG_MODE(DRM_MODESET_DEBUG,
- Modeline %d:\%s\ %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x\n,
+ DRM_DEBUG_MODE(Modeline %d:\%s\ %d %d %d %d %d %d %d %d %d %d
+ 0x%x 0x%x\n,
mode-base.id, mode-name, mode-vrefresh, mode-clock,
mode-hdisplay, mode-hsync_start,
mode-hsync_end, mode-htotal,
@@ -403,8 +402,7 @@
list_del(mode-head);
if (verbose) {
drm_mode_debug_printmodeline(mode);
- DRM_DEBUG_MODE(DRM_MODESET_DEBUG,
- Not using %s mode %d\n,
+ DRM_DEBUG_MODE(Not using %s mode %d\n,
mode-name, mode-status);
}
drm_mode_destroy(dev, mode);
Index: linux-2.6/drivers/gpu/drm/i915/i915_dma.c
===
--- linux-2.6.orig/drivers/gpu/drm/i915/i915_dma.c 2009-07-16
13:53:24.0 +0800
+++ linux-2.6/drivers/gpu/drm/i915/i915_dma.c 2009-07-16 13:53:38.0
+0800
@@ -33,8 +33,6
RE: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
Hello All: I understand the requirement. If we submitted for mainline when everything is ready, I believe it takes very long time. Some of you might know that VIA has been trying to support community by releasing doc, source and submit for upstream step by step. As Harald point out, the docs has been hosted in x.org, 2D source code has been released in public domain. We are now preparing our new 2D source which need DRM support for the 3D HW acceleration for EXA and will release it in public domain within 1 month too. I believe it can be a good start for the DRM verification. It's my understanding community people always welcome people to contribute to community. VIA is starting and is on the way to contribute for better user experience. Maybe VIA is not doing perfect yet now, but I hope we can be encouraged for more contribution to the community. VIA will base on the feedback and keep improving. Please give us time and please don't keep VIA away from the openning way. 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 -Original Message- From: zaj...@gmail.com [mailto:zaj...@gmail.com] Sent: Monday, July 20, 2009 1:23 AM To: Uros Nedic Cc: Harald Welte; dri-devel@lists.sourceforge.net; Richard Lee; gre...@suse.de; Bruce Chang; Joseph Chan; Benjamin Pan (Fremont) Subject: Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream W dniu 19 lipca 2009 18:57 użytkownik Uros Nedic ur...@live.com napisał: If there are small amount of people with enough knowledge to write device drivers, let AMD, VIA, Intel and others make some small one week school and call people from this community to teach them how to do that. This way total cost of writing drivers will be significantly lower (each company should donate some money for this school, and to teach community members) and for return people from community will be educated to do that. It is win-win position - companies get drivers, community gets knowledge. I'm one of the first who would like to write drivers as part of my practice in programming. It is not up to me do decide how my programmer skills are, but I have MSc in Telecommunications Engineering, and also I had many hardware/software oriented exams. I believe for myself that I'm skilled programmer but I'm lacking of knowledge about X Window System, DRI, Gallium3D. To be worse I cannot find any satisfying literature on the Net to start learning. I'm not talking about some 'Tutorials' or 'Introductions' but about some documents where I could understand deeply how it is organized and how to write high quality drivers. I totally agree. Drivers development is really undocumented :/ I have problems understanding how DDX (modesetting) driver works, and most answers I have to get from IRC, not Google. I'm totaly scared of any 3D or even Xv programming. Add the fact that code also lacks documentation and it's extremly hard for some newbie to dig into that. Would be great if someone could document all that, but it seems noone is interested in that. Ppl how already understand that focus on coding, not documenting :/ -- Rafał Miłecki -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Patch 3/4] DRM: Add the explanation about DRM debug level
From: Zhao Yakui yakui.z...@intel.com Add the explanation about DRM debug level in the drmP header file. This is to explain how/where to use the different DRM debug level. Signed-off-by: Zhao Yakui yakui.z...@intel.com --- include/drm/drmP.h | 31 +++ 1 file changed, 31 insertions(+) Index: linux-2.6/include/drm/drmP.h === --- linux-2.6.orig/include/drm/drmP.h 2009-07-16 14:17:00.0 +0800 +++ linux-2.6/include/drm/drmP.h2009-07-16 14:23:33.0 +0800 @@ -88,6 +88,37 @@ #define DRM_UT_CORE0x01 #define DRM_UT_DRIVER 0x02 #define DRM_UT_KMS 0x04 +/* + * Three debug levels are defined. + * drm_core, drm_driver, drm_kms + * drm_core level can be used in the generic drm code. For example: + * drm_ioctl, drm_mm, drm_memory + * The macro definiton of DRM_DEBUG is used. + * DRM_DEBUG(fmt, args...) + * The debug info by using the DRM_DEBUG can be obtained by adding + * the boot option of drm.debug=1. + * + * drm_driver level can be used in the specific drm driver. It is used + * to add the debug info related with the drm driver. For example: + * i915_drv, i915_dma, i915_gem, radeon_drv, + * The macro definition of DRM_DEBUG_DRIVER can be used. + * DRM_DEBUG_DRIVER(fmt, args...) + * The debug info by using the DRM_DEBUG_DRIVER can be obtained by + * adding the boot option of drm.debug=0x02 + * + * drm_kms level can be used in the KMS code related with specific drm driver. + * It is used to add the debug info related with KMS mode. For example: + * the connector/crtc , + * The macro definition of DRM_DEBUG_KMS can be used. + * DRM_DEBUG_KMS(fmt, args...) + * The debug info by using the DRM_DEBUG_KMS can be obtained by + * adding the boot option of drm.debug=0x04 + * + * If we add the boot option of drm.debug=0x06, we can get the debug info by + * using the DRM_DEBUG_KMS and DRM_DEBUG_DRIVER. + * If we add the boot option of drm.debug=0x05, we can get the debug info by + * using the DRM_DEBUG_KMS and DRM_DEBUG. + */ extern void drm_ut_debug_printk(unsigned int request_level, const char *prefix, -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/4] DRM :Add the debug info in generic drm mode by using DRM_DEBUG_KMS
From: Zhao Yakui yakui.z...@intel.com
Add the debug info in generic drm mode by using DRM_DEBUG_KMS
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/drm_crtc.c| 29 +
drivers/gpu/drm/drm_crtc_helper.c | 44 --
2 files changed, 40 insertions(+), 33 deletions(-)
Index: linux-2.6/drivers/gpu/drm/drm_crtc.c
===
--- linux-2.6.orig/drivers/gpu/drm/drm_crtc.c 2009-07-10 08:43:49.0
+0800
+++ linux-2.6/drivers/gpu/drm/drm_crtc.c2009-07-16 14:53:33.0
+0800
@@ -1060,7 +1060,7 @@
if (file_priv-master-minor-type == DRM_MINOR_CONTROL) {
list_for_each_entry(crtc, dev-mode_config.crtc_list,
head) {
- DRM_DEBUG(CRTC ID is %d\n, crtc-base.id);
+ DRM_DEBUG_KMS(CRTC ID is %d\n, crtc-base.id);
if (put_user(crtc-base.id, crtc_id + copied)) {
ret = -EFAULT;
goto out;
@@ -1088,7 +1088,7 @@
list_for_each_entry(encoder,
dev-mode_config.encoder_list,
head) {
- DRM_DEBUG(ENCODER ID is %d\n,
+ DRM_DEBUG_KMS(ENCODER ID is %d\n,
encoder-base.id);
if (put_user(encoder-base.id, encoder_id +
copied)) {
@@ -1119,7 +1119,7 @@
list_for_each_entry(connector,
dev-mode_config.connector_list,
head) {
- DRM_DEBUG(CONNECTOR ID is %d\n,
+ DRM_DEBUG_KMS(CONNECTOR ID is %d\n,
connector-base.id);
if (put_user(connector-base.id,
connector_id + copied)) {
@@ -1143,7 +1143,7 @@
}
card_res-count_connectors = connector_count;
- DRM_DEBUG(Counted %d %d %d\n, card_res-count_crtcs,
+ DRM_DEBUG_KMS(Counted %d %d %d\n, card_res-count_crtcs,
card_res-count_connectors, card_res-count_encoders);
out:
@@ -1246,7 +1246,7 @@
memset(u_mode, 0, sizeof(struct drm_mode_modeinfo));
- DRM_DEBUG(connector id %d:\n, out_resp-connector_id);
+ DRM_DEBUG_KMS(connector id %d:\n, out_resp-connector_id);
mutex_lock(dev-mode_config.mutex);
@@ -1422,7 +1422,7 @@
obj = drm_mode_object_find(dev, crtc_req-crtc_id,
DRM_MODE_OBJECT_CRTC);
if (!obj) {
- DRM_DEBUG(Unknown CRTC ID %d\n, crtc_req-crtc_id);
+ DRM_DEBUG_KMS(Unknown CRTC ID %d\n, crtc_req-crtc_id);
ret = -EINVAL;
goto out;
}
@@ -1435,7 +1435,8 @@
list_for_each_entry(crtcfb,
dev-mode_config.crtc_list, head) {
if (crtcfb == crtc) {
- DRM_DEBUG(Using current fb for
setmode\n);
+ DRM_DEBUG_KMS(Using current fb for
+ setmode\n);
fb = crtc-fb;
}
}
@@ -1443,7 +1444,8 @@
obj = drm_mode_object_find(dev, crtc_req-fb_id,
DRM_MODE_OBJECT_FB);
if (!obj) {
- DRM_DEBUG(Unknown FB ID%d\n, crtc_req-fb_id);
+ DRM_DEBUG_KMS(Unknown FB ID%d\n,
+ crtc_req-fb_id);
ret = -EINVAL;
goto out;
}
@@ -1456,13 +1458,13 @@
}
if (crtc_req-count_connectors == 0 mode) {
- DRM_DEBUG(Count connectors is 0 but mode set\n);
+ DRM_DEBUG_KMS(Count connectors is 0 but mode set\n);
ret = -EINVAL;
goto out;
}
if (crtc_req-count_connectors 0 !mode !fb) {
- DRM_DEBUG(Count connectors is %d but no mode or fb set\n,
+ DRM_DEBUG_KMS(Count connectors is %d but no mode or fb set\n,
crtc_req-count_connectors);
ret = -EINVAL;
goto out;
@@ -1495,7 +1497,8 @@
obj = drm_mode_object_find(dev, out_id,
[Bug 22528] r300 crashes inside radeonTexSubImage2D
http://bugs.freedesktop.org/show_bug.cgi?id=22528 --- Comment #3 from Fabio fabio@libero.it 2009-07-20 01:55:08 PST --- Apparently the demos use a protection library not supported by wine: http://bugs.winehq.org/show_bug.cgi?id=3260 The full game got an updated patch (1.08) that remove the protection but this is not available for the demos. I found however a way to reproduce the problem with the demo + the patch for the full game. Note that due to this hack the demo will not be playable (e.g., whith swrender, after reaching the menu it prints an error message that maps are corrupted). 1) download and install the demo from: http://files.filefront.com/Codename+Panzers+Phase+Two+Demo/;3932312;/fileinfo.html 2) enter the Run directory inside the main game directory and unzip this file which contains the patch + zlib dll and a tga file required by the patch: http://rapidshare.com/files/257867465/panzers-2-demo-patch-1.08.zip.html 3) run the game with: wine PANZERS_PHASE_2_1.08.exe from the Run directory -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13776] KMS with Intel Graphic fails
http://bugzilla.kernel.org/show_bug.cgi?id=13776 --- Comment #15 from mailingli...@openelec.tv 2009-07-20 09:47:52 --- anyone can help me with this? -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16772] Xorg memory leak loading Amarok's Cover Manager
http://bugs.freedesktop.org/show_bug.cgi?id=16772 Mikko C. mikko@gmail.com changed: What|Removed |Added Component|Drivers/DRI/r300|Server/general Product|Mesa|xorg Summary|Memory leak loading Amarok's|Xorg memory leak loading |Cover Manager with git mesa |Amarok's Cover Manager |and xserver | Version|CVS |7.4 --- Comment #17 from Mikko C. mikko@gmail.com 2009-07-20 05:18:13 PST --- I changed the title and product, since it happens with nvidia and intel cards too. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Mon, 2009-07-20 at 11:52 +0800, brucech...@via.com.tw wrote: Hello All: I understand the requirement. If we submitted for mainline when everything is ready, I believe it takes very long time. Some of you might know that VIA has been trying to support community by releasing doc, source and submit for upstream step by step. As Harald point out, the docs has been hosted in x.org, 2D source code has been released in public domain. We are now preparing our new 2D source which need DRM support for the 3D HW acceleration for EXA and will release it in public domain within 1 month too. I believe it can be a good start for the DRM verification. It's my understanding community people always welcome people to contribute to community. VIA is starting and is on the way to contribute for better user experience. Maybe VIA is not doing perfect yet now, but I hope we can be encouraged for more contribution to the community. VIA will base on the feedback and keep improving. Please give us time and please don't keep VIA away from the openning way. I appreciate the efforts that VIA is making towards supporting their customers. I have had users asking me for hardware acceleration with VIA chips in FreeBSD for a while now. Many users will be satisfied with a good hardware accelerated 2D solution. A 3D driver is certainly a nice feature to have and I wonder if it might be possible for VIA to release partial source code for their 3D driver that doesn't include the 3rd party code. That might at least give a good starting point for a complete open driver. I realize that the 3rd party code might be too invasive for that to be possible. I would hope that VIA will be focusing it's resources on providing accurate documentation and hopefully code for currently shipping and future chips. It is difficult with limited resources to go back and change the past. robert. 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 -Original Message- From: zaj...@gmail.com [mailto:zaj...@gmail.com] Sent: Monday, July 20, 2009 1:23 AM To: Uros Nedic Cc: Harald Welte; dri-devel@lists.sourceforge.net; Richard Lee; gre...@suse.de; Bruce Chang; Joseph Chan; Benjamin Pan (Fremont) Subject: Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream W dniu 19 lipca 2009 18:57 uytkownik Uros Nedic ur...@live.com napisa: If there are small amount of people with enough knowledge to write device drivers, let AMD, VIA, Intel and others make some small one week school and call people from this community to teach them how to do that. This way total cost of writing drivers will be significantly lower (each company should donate some money for this school, and to teach community members) and for return people from community will be educated to do that. It is win-win position - companies get drivers, community gets knowledge. I'm one of the first who would like to write drivers as part of my practice in programming. It is not up to me do decide how my programmer skills are, but I have MSc in Telecommunications Engineering, and also I had many hardware/software oriented exams. I believe for myself that I'm skilled programmer but I'm lacking of knowledge about X Window System, DRI, Gallium3D. To be worse I cannot find any satisfying literature on the Net to start learning. I'm not talking about some 'Tutorials' or 'Introductions' but about some documents where I could understand deeply how it is organized and how to write high quality drivers. I totally agree. Drivers development is really undocumented :/ I have problems understanding how DDX (modesetting) driver works, and most answers I have to get from IRC, not Google. I'm totaly scared of any 3D or even Xv programming. Add the fact that code also lacks documentation and it's extremly hard for some newbie to dig into that. Would be great if someone could document all that, but it seems noone is interested in that. Ppl how already understand that focus on coding, not documenting :/ -- Robert Noland rnol...@2hip.net 2Hip Networks -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon: Fix size used for benchmarking BO copies.
On Mon, 2009-07-20 at 01:44 +0200, Michel Dänzer wrote:
From: Michel Dänzer daen...@vmware.com
The incorrect size caused benchmark results to be inflated by a factor of 4.
Whoops, forgot
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/radeon/radeon_benchmark.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c
b/drivers/gpu/drm/radeon/radeon_benchmark.c
index c44403a..2e938f7 100644
--- a/drivers/gpu/drm/radeon/radeon_benchmark.c
+++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
@@ -63,7 +63,7 @@ void radeon_benchmark_move(struct radeon_device *rdev,
unsigned bsize,
if (r) {
goto out_cleanup;
}
- r = radeon_copy_dma(rdev, saddr, daddr, size 14, fence);
+ r = radeon_copy_dma(rdev, saddr, daddr, size / 4096, fence);
if (r) {
goto out_cleanup;
}
@@ -88,7 +88,7 @@ void radeon_benchmark_move(struct radeon_device *rdev,
unsigned bsize,
if (r) {
goto out_cleanup;
}
- r = radeon_copy_blit(rdev, saddr, daddr, size 14, fence);
+ r = radeon_copy_blit(rdev, saddr, daddr, size / 4096, fence);
if (r) {
goto out_cleanup;
}
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22851] New: supertuxkart wont start on 7.6-devel
http://bugs.freedesktop.org/show_bug.cgi?id=22851 Summary: supertuxkart wont start on 7.6-devel Product: Mesa Version: CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: jaku...@hotmail.com Supertuxkart doesn't start after having built latest mesa tree (worked before - on mesa 7.4) Couldnt find out if i have made some mistake compiling since the guide for compiling isnt too userfriendly, especially for newbies like me... and i think ubuntu 7.04 isnt considerd a NEW operating system anymore. thats what shows up in the terminal when starting over it: supertuxkart: radeon_lock.c:65: radeonGetLock: Assertion `drawable != ((void *)0)' failed. Aborted besides, when compiling: do i need the r300 or just the radeon driver compiled? whats the difference etc (there really is no bloody explanation on the net!) hoping i could point something out that could have any kind of importance XD thx for all the work done yet! kind regards jakub -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22851] supertuxkart wont start on 7.6-devel
http://bugs.freedesktop.org/show_bug.cgi?id=22851 Jakub Orlowski jaku...@hotmail.com changed: What|Removed |Added OS/Version|All |Linux (All) Platform|Other |x86-64 (AMD64) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On 201, 07 20, 2009 at 03:38:32PM +0200, Thomas Hellstr?m wrote: Hi! It appears that GPL'd DRM drivers for closed-source user-space clients are becoming more common, and the situation appears to be causing a lot of unnecessary work from people wanting their drivers in the mainstream kernel. Arguments against pushing upstream include. * Security. * User space interface validation and maintainability. * Politics Why should linux kernel developers care about these drivers at all ? * If such driver is accepted it immediately puts compatibility burden on drm developers without any gain for them. * Users are still on mercy of binary blob supplier. Will this blob run on arm ? Or powerpc ? Or even x86_64 ? Will it be compatible with XOrg X.Y ? Nobody knows that and there is no gain for users too. Security: I think from a security point of view, open docs and a thorough documented security analysis by the driver writer should be sufficient. This should include: 1. In what ways can the GPU access random system pages and how is user-space prevented from doing that in the driver? 2. In what ways can the GPU transfer random user data into its own privileged command stream and, if relevant, how is that prevented in the driver? 3. Is the driver capable of maintaining video memory ownership and protecition? (Currently not a requirement) 4. How is user-space prevented from causing the kernel driver to do unlimited allocations of kernel resources, like buffer objects or references to them. I really don't think an open-source user-space client can add much more to this. It can perhaps be used to detect obvious big security flaws but that should be apparent also from the open docs and the security analysis. User-space interface: Historically driver-specific interfaces have really been up to the driver writer and when posted for review they receive very little comments unless there are things like 64/32 bit incompatibilities etc, but as mentioned on the list, small programs that demonstrate the use of all interface functions would be desirable, and very helpful if someone decides to do write an open-source driver. Politics: It's true that sometimes some people don't like the code or what it does. But when this is the underlying cause of NAK-ing a driver I think it's very important that this is clearly stated, instead of inventing various random reasons that can easily be argued against. How should the driver writer otherwise get it right? Man-years might be spent fixing up drivers that will never get upstream anyway. I think it would help a lot of there was a documented set of driver features that were required and sufficient for a DRM driver to go upstream. It could look something like * Kernel coding style obeyed. Passing checkpatch. * short description of underlying driver architecture (GEM / TTM / Traditional) and future plans * Security analysis according to the above. * Open user-space source exercising all functions of the driver or fully open docs. * User-space interface description and relation to future plans. Thanks, /Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
* fully functional GPL user-space driver. How can you argue that something as tailor made as a DRM interface can be used without it being a derived work? Our prior policy has been to reject such stuff (both the Intel wireless driver regulatory daemon and the GMX driver) -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
Christoph Hellwig wrote: I think you're just trying to push your agenda. I think you're just trying to defend your business writing closed source drivers. Drivers that aren't usable without binary blobs don't have a business in the kernel tree, and your whining doesn't help it. You'd be better off spending your time getting proper open drivers done than defending doing the work to support closed binaries. You obviously got all this completely wrong. I avoid writing closed source drivers whenever I can, I'm not whining and I'm not trying to push any of them. The code VIA is trying to submit has not been written by me nor anybody I know. All VIA code I and the companies I've worked for has written is open-sourced and contributed to the Openchrome / mesa / drm project. The point I'm trying to make is the following: If the common agreement of the linux community is to *NOT* allow these drivers in, so be it, then be honest and go ahead and tell the driver writers. Don't make them respin their development trying to fix minor flaws when their driver won't get in anyway! /Thomas -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22852] New: [r300 KMS] modesetting not accepted by monitor
http://bugs.freedesktop.org/show_bug.cgi?id=22852 Summary: [r300 KMS] modesetting not accepted by monitor Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: aelschur...@hotmail.com Created an attachment (id=27849) -- (http://bugs.freedesktop.org/attachment.cgi?id=27849) dmesg. At 1s I switched from 6.12.2 driver to 6.12.99 Using kernel modesetting, one of my two monitors does not accept any mode set via xrandr, nor does it accept the default mode set during boot. The other monitor works fine, but xrandr shows less modes than with an older driver. -- I'm currently testing the radeon modesetting features on my Radeon 9550. My system has X.org from Debian unstable, a manually-compiled Linux kernel with kms enabled, and Radeon drivers from the Ubuntu PPA xorg-edgers/radeon-kms (https://launchpad.net/~xorg-edgers/+archive/radeon-kms). relevant package versions: xserver-xorg-core 2:1.6.2-1 xserver-xorg-video-ati 1:6.12.99+git20090719 xserver-xorg-video-radeon 1:6.12.99+git20090719 libdrm22.4.12+git20090717 libdrm-radeon1 2.4.12+git20090717 libgl1-mesa-dri7.6.0~git20090715 linux-image-2.6.31-rc3 2.6.31-rc3-10.00.Custom Reverting to the 6.12.2 driver from Debian unstable brings the second monitor back to life. The modelines generated by both drivers appear identical, but in the radeon-kms case, I get the following lines in /var/log/kern.log: Jul 20 15:35:37 neminis kernel: [13998.608038] [drm] TMDS-8: set mode 35 Jul 20 15:36:16 neminis kernel: [14036.829106] [drm] TMDS-8: set mode 41 The monitor does flicker on and off when I switch between xrandr --off and xrandr --auto, so the port appears correct. I'm running without xorg.conf, so everything is auto-detected. I'll attach both Xorg logs in a minute. But as for the video modes, XRandr doesn't agree either (VGA-0 = working, DVI-0 = modes not accepted by monitor): == xrandr-6.12.2 == Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1920 x 1920 VGA-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 340mm x 270mm 1280x1024 75.0*+ 60.0 1152x864 75.0 1024x768 75.0 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 56.2 640x48075.0 72.8 66.7 59.9 720x40070.1 DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 521mm x 293mm 1920x1080 60.0 + 1680x1050 59.9 1280x1024 75.0 60.0* 1440x900 75.0 59.9 1280x960 60.0 1152x864 75.0 1024x768 75.0 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 56.2 640x48075.0 72.8 66.7 59.9 == xrandr-6.12.99 == Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 4096 x 4096 VGA-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 340mm x 270mm 1280x1024 75.0*+ 1024x768 75.1 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 56.2 640x48072.8 75.0 66.7 60.0 720x40070.1 0x0 0.0 DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 521mm x 293mm 1920x1080 60.0 + 1280x1024 75.0* 1024x768 75.1 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 56.2 640x48072.8 75.0 66.7 60.0 720x40070.1 0x0 0.0 (parts of) this could be related to #22638, but it doesn't appear to be the same issue. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22852] [r300 KMS] modesetting not accepted by monitor
http://bugs.freedesktop.org/show_bug.cgi?id=22852 --- Comment #1 from Arno Schuring aelschur...@hotmail.com 2009-07-20 08:06:45 PST --- Created an attachment (id=27850) -- (http://bugs.freedesktop.org/attachment.cgi?id=27850) Xorg.log from (working) 6.12.2 driver -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
Peter Zijlstra wrote: On Mon, 2009-07-20 at 15:38 +0200, Thomas Hellström wrote: Politics: It's true that sometimes some people don't like the code or what it does. But when this is the underlying cause of NAK-ing a driver I think it's very important that this is clearly stated, instead of inventing various random reasons that can easily be argued against. How should the driver writer otherwise get it right? Man-years might be spent fixing up drivers that will never get upstream anyway. I think it would help a lot of there was a documented set of driver features that were required and sufficient for a DRM driver to go upstream. It could look something like * Kernel coding style obeyed. Passing checkpatch. * fully functional GPL user-space driver. How can you argue that something as tailor made as a DRM interface can be used without it being a derived work? FWIW my full vote goes against allowing such thing to happen, and I think quite a lot of kernel people would agree with me. I would hope enough of of them would so that we can stop this from happening. Negative karma points to you for trying to chip away at the spirit of As stated before this was a suggestion to clarify the field for driver writers. If the documented set of driver features required is fully open-source so be it. Just let people know. /Thomas Linux. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22852] [r300 KMS] modesetting not accepted by monitor
http://bugs.freedesktop.org/show_bug.cgi?id=22852 --- Comment #2 from Arno Schuring aelschur...@hotmail.com 2009-07-20 08:08:00 PST --- Created an attachment (id=27851) -- (http://bugs.freedesktop.org/attachment.cgi?id=27851) Xorg.log with (non-working) 6.12.99 driver -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
If the common agreement of the linux community is to *NOT* allow these drivers in, so be it, then be honest and go ahead and tell the driver writers. Don't make them respin their development trying to fix minor flaws when their driver won't get in anyway! The existing policy based on what has been rejected is: - If you have something which only works with some non-free tightly integrated software then we don't accept it Examples - GMX500, Intel wireless regulatory daemon. So until there is an open source user and test case for the kernel code it has no place in the kernel (and indeed if the two are closely interconnected and dependent then there are good 'talk to your lawyer' reasons as well) Once there is a useful combination of kernel/user space free software for the card then it makes sense to look at a merge. Until then you don't even know what the final interface will look like and what is actually needed kernel side. The VIA stuff might be a useful basis for that work but that is a when/if anyone ever writes drivers for it. My guess is that if someone cares enough about the hardware they need to get EXA working along with 2D render, then submit the bits the need to do hardware rendering. After that tackle what is needed for 3D - as is happening with the Nvidia drivers and then submit a DRM module for their work. Alan -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22852] [r300 KMS] modesetting not accepted by monitor
http://bugs.freedesktop.org/show_bug.cgi?id=22852 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #27849|application/octet-stream|text/plain mime type|| Attachment #27849|0 |1 is patch|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22852] [r300 KMS] modesetting not accepted by monitor
http://bugs.freedesktop.org/show_bug.cgi?id=22852 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #27850|application/octet-stream|text/plain mime type|| Attachment #27850|0 |1 is patch|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22852] [r300 KMS] modesetting not accepted by monitor
http://bugs.freedesktop.org/show_bug.cgi?id=22852 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #27851|application/octet-stream|text/plain mime type|| Attachment #27851|0 |1 is patch|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Mon, Jul 20, 2009 at 04:52:26PM +0100, Matthew Garrett wrote: I think tightly integrated could do with some clarification here. qcserial was accepted despite not being functional without a closed userspace component - an open one's since been rewritten to allow it to work. Do we define tightly integrated as likely to cross the GPL line (potentially the case with Poulsbo, not the case with qcserial), or is it a pragmatic issue? What about specialised hardware drivers that only have closed applications? Greg still claims that qcserial could be used by rebooting from Windows, right? In that it would still be extremly borderline to me, but it's settled now. We also have various SCSI HBA drivers that can be used just fine, but contain tons ot ioctls for management tools that aren't available as open source (or even easily obtainable at all). Personally I don't think we should merge those unless we have userspace code available freely, but it's a less urgent issue than merging drivers that can't be used at all. The DRM modules fall to me exactly into that category for specialised hardware drivers that only have closed applications, and the answer to those should be a clear no. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm: Fixing compilers warnings
From 3eb4a3493f13c48bee1b2453f5ecead0ba498c51 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Mon, 20 Jul 2009 15:45:41 +0300
Subject: [PATCH 05/15] libdrm: Fix drmOpenDevice to take dev_t type as
parameter.
This fixes signed/unsigned comparission between st.st_dev and dev.
---
libdrm/xf86drm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libdrm/xf86drm.c b/libdrm/xf86drm.c
index d168258..30e9616 100644
--- a/libdrm/xf86drm.c
+++ b/libdrm/xf86drm.c
@@ -323,7 +323,7 @@ static int chown_check_return(const char *path,
uid_t owner, gid_t group)
* special file node with the major and minor numbers specified by \p dev and
* parent directory if necessary and was called by root.
*/
-static int drmOpenDevice(long dev, int minor, int type)
+static int drmOpenDevice(dev_t dev, int minor, int type)
{
stat_t st;
charbuf[64];
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm: Fixing compilers warnings
From 78bfacedfb3b81968b2171a942101d323b1782cb Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Mon, 20 Jul 2009 15:48:48 +0300
Subject: [PATCH 06/15] libdrm: Fix loop index variable type to match
the type of count
---
libdrm/xf86drm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libdrm/xf86drm.c b/libdrm/xf86drm.c
index 30e9616..2507829 100644
--- a/libdrm/xf86drm.c
+++ b/libdrm/xf86drm.c
@@ -2177,8 +2177,8 @@ int drmGetClient(int fd, int idx, int *auth, int
*pid, int *uid,
int drmGetStats(int fd, drmStatsT *stats)
{
-drm_stats_t s;
-int i;
+drm_stats_t s;
+unsigned long i;
if (drmIoctl(fd, DRM_IOCTL_GET_STATS, s))
return -errno;
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm: Fixing compilers warnings
From 10a9bf298be4695242bcdb63bcfad720e03bf040 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Mon, 20 Jul 2009 16:31:54 +0300
Subject: [PATCH 08/15] libdrm: Make gcc to understand that pointers
are realy pointers.
---
libdrm/xf86drmSL.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libdrm/xf86drmSL.c b/libdrm/xf86drmSL.c
index 58aefac..22e3b92 100644
--- a/libdrm/xf86drmSL.c
+++ b/libdrm/xf86drmSL.c
@@ -335,16 +335,16 @@ void drmSLDump(void *l)
list-magic, SL_ENTRY_MAGIC);
}
printf(\nEntry %p 0x%08lx, %p has %2d levels\n,
- entry, entry-key, entry-value, entry-levels);
+ (void*)entry, entry-key, entry-value, entry-levels);
for (i = 0; i entry-levels; i++) {
if (entry-forward[i]) {
printf( %2d: %p 0x%08lx, %p\n,
i,
- entry-forward[i],
+ (void*)entry-forward[i],
entry-forward[i]-key,
entry-forward[i]-value);
} else {
- printf( %2d: %p\n, i, entry-forward[i]);
+ printf( %2d: %p\n, i, (void*)entry-forward[i]);
}
}
}
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm: Fixing compilers warnings
From 7fcfbf715644d2268236b8a19d1f2f83c952d72b Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Mon, 20 Jul 2009 16:25:59 +0300
Subject: [PATCH 07/15] libdrm: Fix random number generator to use unsigned seed.
This fixes wanring about unsigned/signed comparision.
Also make it easier to compile test program using -D switch.
---
libdrm/xf86drmRandom.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/libdrm/xf86drmRandom.c b/libdrm/xf86drmRandom.c
index ecab9e2..f488630 100644
--- a/libdrm/xf86drmRandom.c
+++ b/libdrm/xf86drmRandom.c
@@ -74,7 +74,9 @@
#include stdio.h
#include stdlib.h
+#ifndef RANDOM_MAIN
#define RANDOM_MAIN 0
+#endif
#if !RANDOM_MAIN
# include xf86drm.h
@@ -98,7 +100,7 @@ typedef struct RandomState {
unsigned long q; /* m div a */
unsigned long r; /* m mod a */
unsigned long check;
-long seed;
+unsigned long seed;
} RandomState;
#if RANDOM_MAIN
@@ -153,7 +155,7 @@ unsigned long drmRandom(void *state)
hi = s-seed / s-q;
lo = s-seed % s-q;
s-seed = s-a * lo - s-r * hi;
-if (s-seed = 0) s-seed += s-m;
+if (s-seed s-m) s-seed += s-m;
return s-seed;
}
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm: Fixing compilers warnings
From 69cad004e5355e4adcee753de4da91c98949d3df Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Mon, 20 Jul 2009 16:50:20 +0300
Subject: [PATCH 09/15] libdrm: Make drmAllocCpy static.
---
libdrm/xf86drmMode.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libdrm/xf86drmMode.c b/libdrm/xf86drmMode.c
index ea11207..180d3ef 100644
--- a/libdrm/xf86drmMode.c
+++ b/libdrm/xf86drmMode.c
@@ -55,7 +55,7 @@
* Util functions
*/
-void* drmAllocCpy(void *array, int count, int entry_size)
+static void* drmAllocCpy(void *array, int count, int entry_size)
{
char *r;
int i;
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm: Fixing compilers warnings
From 6ad9d2f1495df9bbdecbe4e7676da75d48ba3719 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Mon, 20 Jul 2009 16:55:21 +0300
Subject: [PATCH 10/15] libdrm: Make drmAllocCpy use only single memcpy
call instead of calling memcpy in loop.
---
libdrm/xf86drmMode.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/libdrm/xf86drmMode.c b/libdrm/xf86drmMode.c
index 180d3ef..0d080b8 100644
--- a/libdrm/xf86drmMode.c
+++ b/libdrm/xf86drmMode.c
@@ -58,7 +58,6 @@
static void* drmAllocCpy(void *array, int count, int entry_size)
{
char *r;
- int i;
if (!count || !array || !entry_size)
return 0;
@@ -66,8 +65,7 @@ static void* drmAllocCpy(void *array, int count, int
entry_size)
if (!(r = drmMalloc(count*entry_size)))
return 0;
- for (i = 0; i count; i++)
- memcpy(r+(entry_size*i), array+(entry_size*i), entry_size);
+ memcpy(r, array, count*entry_size);
return r;
}
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm: Fixing compilers warnings
From 9043299720ef5ecac1fe575b0bbda19b81720dd8 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Mon, 20 Jul 2009 18:00:43 +0300
Subject: [PATCH 13/15] libdrm/radeon: Remove unussed variables and
make printf happy with explicity void* cast from struct radeon_bo*.
---
libdrm/radeon/radeon_bo.h |2 +-
libdrm/radeon/radeon_bo_gem.c |4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/libdrm/radeon/radeon_bo.h b/libdrm/radeon/radeon_bo.h
index 597d0ef..3bb15af 100644
--- a/libdrm/radeon/radeon_bo.h
+++ b/libdrm/radeon/radeon_bo.h
@@ -84,7 +84,7 @@ static inline void _radeon_bo_debug(struct radeon_bo *bo,
int line)
{
fprintf(stderr, %s %p 0x%08X 0x%08X 0x%08X [%s %s %d]\n,
-op, bo, bo-handle, bo-size, bo-cref, file, func, line);
+op, (void*)bo, bo-handle, bo-size, bo-cref, file, func, line);
}
static inline struct radeon_bo *_radeon_bo_open(struct radeon_bo_manager *bom,
diff --git a/libdrm/radeon/radeon_bo_gem.c b/libdrm/radeon/radeon_bo_gem.c
index 558b93a..4ebf986 100644
--- a/libdrm/radeon/radeon_bo_gem.c
+++ b/libdrm/radeon/radeon_bo_gem.c
@@ -162,7 +162,7 @@ static int bo_map(struct radeon_bo *bo, int write)
sizeof(args));
if (r) {
fprintf(stderr, error mapping %p 0x%08X (error = %d)\n,
-bo, bo-handle, r);
+(void*)bo, bo-handle, r);
return r;
}
ptr = mmap(0, args.size, PROT_READ|PROT_WRITE, MAP_SHARED,
bo-bom-fd, args.addr_ptr);
@@ -239,7 +239,6 @@ uint32_t radeon_gem_name_bo(struct radeon_bo *bo)
int radeon_gem_get_kernel_name(struct radeon_bo *bo, uint32_t *name)
{
-struct radeon_bo_gem *bo_gem = (struct radeon_bo_gem*)bo;
struct drm_gem_flink flink;
int r;
@@ -254,7 +253,6 @@ int radeon_gem_get_kernel_name(struct radeon_bo
*bo, uint32_t *name)
int radeon_gem_set_domain(struct radeon_bo *bo, uint32_t
read_domains, uint32_t write_domain)
{
-struct radeon_bo_gem *bo_gem = (struct radeon_bo_gem*)bo;
struct drm_radeon_gem_set_domain args;
int r;
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm: Fixing compilers warnings
From dea4cebdb49556ab06930bd5a4d303ce1c0b85c7 Mon Sep 17 00:00:00 2001 From: Pauli Nieminen suok...@gmail.com Date: Mon, 20 Jul 2009 17:19:55 +0300 Subject: [PATCH 12/15] intel: Move debug output after setting the value. --- libdrm/intel/intel_bufmgr_fake.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libdrm/intel/intel_bufmgr_fake.c b/libdrm/intel/intel_bufmgr_fake.c index 969c03d..7259690 100644 --- a/libdrm/intel/intel_bufmgr_fake.c +++ b/libdrm/intel/intel_bufmgr_fake.c @@ -287,10 +287,10 @@ _fence_wait_internal(drm_intel_bufmgr_fake *bufmgr_fake, int seq) return; } - DBG(wait 0x%08x\n, iw.irq_seq); - iw.irq_seq = seq; + DBG(wait 0x%08x\n, iw.irq_seq); + /* The kernel IRQ_WAIT implementation is all sorts of broken. * 1) It returns 1 to 0x7fff instead of using the full 32-bit unsigned *range. -- 1.6.3.3 -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm: Fixing compilers warnings
From 0c8b7939fc95084d77063eb8de78b0724d3d4058 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Mon, 20 Jul 2009 17:00:45 +0300
Subject: [PATCH 11/15] libdrm: Make pci id numbers unsigned for sscanf.
---
libdrm/xf86drmMode.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/libdrm/xf86drmMode.c b/libdrm/xf86drmMode.c
index 0d080b8..9b4d5fb 100644
--- a/libdrm/xf86drmMode.c
+++ b/libdrm/xf86drmMode.c
@@ -574,7 +574,8 @@ int drmCheckModesettingSupported(const char *busid)
{
#ifdef __linux__
char pci_dev_dir[1024];
- int domain, bus, dev, func;
+ unsigned int domain, bus, dev;
+ int func;
DIR *sysdir;
struct dirent *dent;
int found = 0, ret;
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm: Fixing compilers warnings
From 9c0cd0ba5bb5966498cad2c5a8c69ec24c4c8e34 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Mon, 20 Jul 2009 18:40:49 +0300
Subject: [PATCH 15/15] Fix signed/unsigned comparison warning
---
libdrm/radeon/radeon_cs_gem.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/libdrm/radeon/radeon_cs_gem.c b/libdrm/radeon/radeon_cs_gem.c
index 264b067..43b136f 100644
--- a/libdrm/radeon/radeon_cs_gem.c
+++ b/libdrm/radeon/radeon_cs_gem.c
@@ -354,21 +354,22 @@ static void cs_gem_print(struct radeon_cs *cs, FILE *file)
unsigned opcode;
unsigned reg;
unsigned cnt;
-int i, j;
+unsigned i,j;
for (i = 0; i cs-cdw;) {
-cnt = CP_PACKET_GET_COUNT(cs-packets[i]);
+/* First word in CP is not counted so has to add one to value */
+cnt = CP_PACKET_GET_COUNT(cs-packets[i]) + 1;
switch (CP_PACKET_GET_TYPE(cs-packets[i])) {
case PACKET_TYPE0:
-fprintf(file, Pkt0 at %d (%d dwords):\n, i, cnt + 1);
+fprintf(file, Pkt0 at %d (%d dwords):\n, i, cnt);
reg = CP_PACKET0_GET_REG(cs-packets[i]);
if (CP_PACKET0_GET_ONE_REG_WR(cs-packets[i++])) {
-for (j = 0; j = cnt; j++) {
+for (j = 0; j cnt; j++) {
fprintf(file, 0x%08X - 0x%04X\n,
cs-packets[i++], reg);
}
} else {
-for (j = 0; j = cnt; j++) {
+for (j = 0; j cnt; j++) {
fprintf(file, 0x%08X - 0x%04X\n,
cs-packets[i++], reg);
reg += 4;
@@ -410,7 +411,7 @@ static void cs_gem_print(struct radeon_cs *cs, FILE *file)
fprintf(file, Unknow opcode 0x%02X at %d\n, opcode, i);
return;
}
-for (j = 0; j = cnt; j++) {
+for (j = 0; j cnt; j++) {
fprintf(file, 0x%08X\n, cs-packets[i++]);
}
break;
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm: Fixing compilers warnings
From 36aef4bf07154ef6d206f15ff1c036a7f8e368a9 Mon Sep 17 00:00:00 2001 From: Pauli Nieminen suok...@gmail.com Date: Mon, 20 Jul 2009 18:33:03 +0300 Subject: [PATCH 14/15] libdrm/radeon: Add config.h include to enable POSIX extensions for strdup call. --- libdrm/radeon/radeon_track.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/libdrm/radeon/radeon_track.c b/libdrm/radeon/radeon_track.c index 1623906..09f8725 100644 --- a/libdrm/radeon/radeon_track.c +++ b/libdrm/radeon/radeon_track.c @@ -27,6 +27,9 @@ * Authors: * Jérôme Glisse gli...@freedesktop.org */ +#ifdef HAVE_CONFIG_H +#include config.h +#endif #include stdio.h #include stdlib.h #include string.h -- 1.6.3.3 -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
Greg still claims that qcserial could be used by rebooting from Windows, right? In that it would still be extremly borderline to me, but it's qcserial has a firmware loader app nowdays (someone wrote one in April) http://www.codon.org.uk/~mjg59/gobi_loader/ indeed Matthew wrote it 8) -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22372] radeon_mipmap_tree.c:114: compute_tex_image_offset: Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=22372 Tilman Sauerbeck til...@code-monkey.de changed: What|Removed |Added CC||til...@code-monkey.de --- Comment #3 from Tilman Sauerbeck til...@code-monkey.de 2009-07-20 10:34:42 PST --- I can reproduce this assertion failure with the tip of Mesa's master branch and demo1 in Doom3. In this case, the texture is not compressed (texImage-IsCompressed is GL_FALSE), but texImage-TexFormat-TexelBytes is 0. Thus radeon_miptree_create() will create a mipmap tree that has mt-bpp set to zero. When lvl-size is computed in radeon_mipmap_tree.c:111, we end up with lvl-rowstride being zero due to multiplying by mt-bpp and thus lvl-size is zero as well. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug #12765] i915 VT switch with AIGLX causes X lock up
On Sun, 28 Jun 2009 21:11:30 +0100 Sitsofe Wheeler sits...@yahoo.com wrote: On Sun, Jun 07, 2009 at 12:06:18PM +0200, Rafael J. Wysocki wrote: Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765 Subject : i915 VT switch with AIGLX causes X lock up Submitter : Sitsofe Wheeler sits...@yahoo.com Date: 2009-02-21 15:38 (107 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec References : http://marc.info/?l=linux-kernelm=123523074304955w=4 http://lkml.org/lkml/2009/4/27/317 Handled-By : Jesse Barnes jbar...@virtuousgeek.org Patch: http://patchwork.kernel.org/patch/20197/ Still here on 2.6.31-rc1 but... ...this seems to be tied to the version of the Intel X drivers I have. On another install with more recent Intel X drivers I cannot reproduce this issue. I guess we can mark it closed then, though I don't have the commit id of the fix handy... -- Jesse Barnes, Intel Open Source Technology Center -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm: Fixing compilers warnings
And then follows fixes for all tests.
From 1cd7a914be3fc5ee8aabdd2297710f5c781b555f Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Mon, 20 Jul 2009 21:36:57 +0300
Subject: [PATCH 1/4] libdrm/tests: Fix compiler warnings in dristat.c.
---
tests/dristat.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/tests/dristat.c b/tests/dristat.c
index 48c3b51..2551f82 100644
--- a/tests/dristat.c
+++ b/tests/dristat.c
@@ -26,7 +26,9 @@
* Authors: Rickard E. (Rik) Faith fa...@valinux.com
*
*/
-
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
#include stdio.h
#include stdlib.h
#include unistd.h
@@ -96,6 +98,7 @@ static void getvm(int fd)
case DRM_SHM:typename = SHM; break;
case DRM_AGP:typename = AGP; break;
case DRM_SCATTER_GATHER: typename = SG; break;
+ case DRM_CONSISTENT: typename = CON; break;
default: typename = ???; break;
}
@@ -108,7 +111,7 @@ static void getvm(int fd)
flagname[6] = '\0';
printf(%4d 0x%08lx 0x%08lx %3.3s %6.6s 0x%08lx ,
- i, offset, (unsigned long)size, typename, flagname, handle);
+ i, (unsigned long)offset, (unsigned long)size, typename, flagname, (unsigned long)handle);
if (mtrr 0) printf(none\n);
else printf(%4d\n, mtrr);
}
@@ -133,7 +136,8 @@ static void getclients(int fd)
sprintf(buf, /proc/%d/cmdline, pid);
memset(cmd, 0, sizeof(cmd));
if ((procfd = open(buf, O_RDONLY, 0)) = 0) {
- read(procfd, cmd, sizeof(cmd)-1);
+ while (read(procfd, cmd, sizeof(cmd)-1) == -1 errno == EINTR)
+ {}
close(procfd);
}
if (*cmd) {
@@ -184,7 +188,7 @@ static void printhuman(unsigned long value, const char *name, int mult)
static void getstats(int fd, int i)
{
drmStatsT prev, curr;
-int j;
+unsigned int j;
doublerate;
printf( System statistics:\n);
--
1.6.3.3
From c7926a7f1e738bf8dbafc7e5fb8e25e1f0b3f6a8 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Mon, 20 Jul 2009 21:37:54 +0300
Subject: [PATCH 2/4] libdrm/tests: Fix compiler warnings in drmstat.c.
---
tests/drmstat.c | 33 +
1 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/tests/drmstat.c b/tests/drmstat.c
index ed2aeb6..cea97db 100644
--- a/tests/drmstat.c
+++ b/tests/drmstat.c
@@ -28,6 +28,7 @@
*
*/
+#include alloca.h
#include stdio.h
#include stdlib.h
#include unistd.h
@@ -69,13 +70,15 @@ static void getversion(int fd)
printf( No driver available\n );
}
}
-
-void handler(int fd, void *oldctx, void *newctx)
+
+#if 0
+static void handler(int fd, void *oldctx, void *newctx)
{
printf(Got fd %d\n, fd);
}
+#endif
-void process_sigio(char *device)
+static void process_sigio(char *device)
{
int fd;
@@ -89,6 +92,13 @@ void process_sigio(char *device)
for (;;) sleep(60);
}
+#define system(command) \
+ do { \
+ int rv = system(command); \
+ if (rv == 0) \
+ exit(1); \
+ } while(0);
+
int main(int argc, char **argv)
{
intc;
@@ -104,6 +114,7 @@ int main(int argc, char **argv)
intloops;
char buf[1024];
inti;
+ unsigned int j;
drmBufInfoPtr info;
drmBufMapPtr bufs;
drmLockPtr lock;
@@ -115,7 +126,10 @@ int main(int argc, char **argv)
case 'F':
count = strtoul(optarg, NULL, 0);
if (!fork()) {
- dup(fd);
+ if (dup(fd) != -1)
+ {
+ exit(1);
+ }
sleep(count);
}
close(fd);
@@ -278,7 +292,7 @@ int main(int argc, char **argv)
drmError(r, argv[0]);
return 1;
}
- printf(0x%04lx byte shm added at 0x%08lx\n, size, handle);
+ printf(0x%04lx byte shm added at 0x%08lx\n, size, (unsigned long)handle);
sprintf(buf, cat /proc/dri/0/vm);
system(buf);
break;
@@ -326,9 +340,9 @@ int main(int argc, char **argv)
printf(\n);
if (c == 'w') {
printf(= WRITING =\n);
- for (i = 0; i size; i+=2) {
- ((char *)address)[i] = i 0xff;
- ((char *)address)[i+1] = i 0xff;
+ for (j = 0; j size; j+=2) {
+ ((char *)address)[j] = j 0xff;
+ ((char *)address)[j+1] = j 0xff;
}
}
printf(= READING =\n);
@@ -414,6 +428,9 @@ int main(int argc, char **argv)
return r;
}
+void
+xf86VDrvMsgVerb(int scrnIndex, int type, int verb, const char *format,
+va_list args) __attribute__((format(printf, 4, 0)));
void
xf86VDrvMsgVerb(int scrnIndex, int type, int verb, const char *format,
--
1.6.3.3
From 654356f6625bac34003313a3d7c54cb7b21df706 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Mon, 20 Jul 2009 21:39:02 +0300
Subject: [PATCH 3/4] libdrm/tests: Fix compiler warnings in modeprint.c.
---
tests/modeprint/modeprint.c | 31 +--
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/tests/modeprint/modeprint.c
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
You obviously got all this completely wrong. I avoid writing closed source drivers whenever I can, I'm not whining and I'm not trying to push any of them. The code VIA is trying to submit has not been written by me nor anybody I know. All VIA code I and the companies I've worked for has written is open-sourced and contributed to the Openchrome / mesa / drm project. The point I'm trying to make is the following: If the common agreement of the linux community is to *NOT* allow these drivers in, so be it, then be honest and go ahead and tell the driver writers. Don't make them respin their development trying to fix minor flaws when their driver won't get in anyway! I would like to raise a couple of real-life issues I have in mind: * First example, let's say VIA gets their Chrome9 DRM merged into the kernel. Now let's say I reverse engineer the hardware (or use the docs whenever they're available) and write a 3D component that needs modifications to the existing DRM interface (or maybe I realize I need a completely new DRM). Then who gets the upper hand? Do I have to keep compatibility with user space binary modules that I do not care about? * Second example, what is the policy if we find security holes in the DRM for a closed user-space afterwards? This breaks the initial promise of security, does that get the driver removed then? Or what if the promise is pending updated documentation that never arrives? * Third example, what if down the line we need changes in the DRM that require updating all DRM modules. Do we (we as in DRM developers) touch the DRM files for the VIA Chrome9 stuff, at the risk of breaking the code (since we don't test with proprietary modules)? Or do we let the Chrome9 files as-is, keeping the old DRM infrastructure and therefore add more and more DRM cruft? In my opinion, accepting GPL'ed DRM modules that support binary user space components is like opening pandora's box. Stephane -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
2009/7/21 Peter Zijlstra pet...@infradead.org: On Mon, 2009-07-20 at 15:38 +0200, Thomas Hellström wrote: Politics: It's true that sometimes some people don't like the code or what it does. But when this is the underlying cause of NAK-ing a driver I think it's very important that this is clearly stated, instead of inventing various random reasons that can easily be argued against. How should the driver writer otherwise get it right? Man-years might be spent fixing up drivers that will never get upstream anyway. I think it would help a lot of there was a documented set of driver features that were required and sufficient for a DRM driver to go upstream. It could look something like * Kernel coding style obeyed. Passing checkpatch. * fully functional GPL user-space driver. How can you argue that something as tailor made as a DRM interface can be used without it being a derived work? For a start the userspace is MIT licensed generally, also with architectures such as gallium3D you can't easily say a driver is derived from the kernel interface. Actually generally the argument is the drm interface would be derived work of the userspace. Kernel hackers aren't lawyers so I cringe whenever one of them says derived work, without understanding that 80-90% of the code is probably in the userspace 3D driver, so proving its derived from a 1000 line kernel interface is where it gets messy, and hence why a number of lawyers for Intel have already come down on thinking it was acceptable and from what I can see are still shipping kernels with an open drm but a closed userspace. So I'm not saying I agree with having these I'm just saying its not your 1000 line regulatory daemon case. Dave. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
Stephane Marchesin wrote: You obviously got all this completely wrong. I avoid writing closed source drivers whenever I can, I'm not whining and I'm not trying to push any of them. The code VIA is trying to submit has not been written by me nor anybody I know. All VIA code I and the companies I've worked for has written is open-sourced and contributed to the Openchrome / mesa / drm project. The point I'm trying to make is the following: If the common agreement of the linux community is to *NOT* allow these drivers in, so be it, then be honest and go ahead and tell the driver writers. Don't make them respin their development trying to fix minor flaws when their driver won't get in anyway! Stephane, Some comments on how these things has been handled / could be handled. I would like to raise a couple of real-life issues I have in mind: * First example, let's say VIA gets their Chrome9 DRM merged into the kernel. Now let's say I reverse engineer the hardware (or use the docs whenever they're available) and write a 3D component that needs modifications to the existing DRM interface (or maybe I realize I need a completely new DRM). Then who gets the upper hand? Do I have to keep compatibility with user space binary modules that I do not care about? If there is a serious OS project, I'd start a new DRM driver. That's sort of what may happen with openChrome vs via.. * Second example, what is the policy if we find security holes in the DRM for a closed user-space afterwards? This breaks the initial promise of security, does that get the driver removed then? Or what if the promise is pending updated documentation that never arrives? I'd say the DRM driver gets disabled unless fixed. How would we handle that problem today with, for example, the SiS driver? * Third example, what if down the line we need changes in the DRM that require updating all DRM modules. Do we (we as in DRM developers) touch the DRM files for the VIA Chrome9 stuff, at the risk of breaking the code (since we don't test with proprietary modules)? Or do we let the Chrome9 files as-is, keeping the old DRM infrastructure and therefore add more and more DRM cruft? Again, this has been done quite commonly in the past and was easier to get right with the old drm.git testing ground. Same issue with unmaintained drivers with OS user-space. Who has actually tested all the drivers when making such a change? I certainly haven't. The change was left for testing for a while in drm.git before Dave moved it upstream. In my opinion, accepting GPL'ed DRM modules that support binary user space components is like opening pandora's box. Stephane Yeah, drivers supporting binary blobs only is out of the question as it seems. Now's the tricky question how do we handle VIA's patches where they claim they have an open-source 2D component that exercises all of the DRM module for EXA render acceleration, and on top of this the 3D binary driver that apparently uses no additional DRM functionality compared to the 2D component? In the ideal world I'd of course like to see a Chrome9 3D driver based of the new openChrome drm driver with a modern GPU memory manager, kernel modesetting and Gallium, but that's a dedicated man-year or more away if / when someone decides to work on it. /Thomas -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Sun, Jul 19, 2009 at 07:18:55PM +0200, Rafał Miłecki wrote: Did VIA consider cooperation with distributions? Maybe they could sponsor some single Mesa developers? What about The Linux Driver Project: http://linuxdriverproject.org/ ? Maybe they would like to cooperate? I'm looking for some solutions VIA could use without giving out a lot of money. How can a developer work on such a driver without sufficient documentation existing? Yes, with thousands of pages of actual manual (not just register dumps) you can do that. And yes, with access to the not-opensource-able driver, you can too. But without both? Very difficult. Both VIA and myself have a good relation to Greg K-H from the linux driver project. But how would we dare to ask somebody to help at a seemingly impossible task? -- - Harald Welte haraldwe...@viatech.comhttp://linux.via.com.tw/ VIA Free and Open Source Software Liaison -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
Andrey Panin pa...@centrinvest.ru writes: * Users are still on mercy of binary blob supplier. Will this blob run on arm ? Or powerpc ? Or even x86_64 ? Will it be compatible with XOrg X.Y ? Nobody knows that and there is no gain for users too. Actually there is a loss - users see the kernel (or partial) driver and think it's open source solution. Been there, it wasn't nice at start and even less nice when the thing chose not to work as advertised. This was (is?) also the case with NVidia graphics drivers, I know many people who purchased their cards thinking they are fully open-source (because their drivers had to be compiled). -- Krzysztof Halasa -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Mon, Jul 20, 2009 at 04:16:20PM +0100, Alan Cox wrote: If the common agreement of the linux community is to *NOT* allow these drivers in, so be it, then be honest and go ahead and tell the driver writers. Don't make them respin their development trying to fix minor flaws when their driver won't get in anyway! The existing policy based on what has been rejected is: - If you have something which only works with some non-free tightly integrated software then we don't accept it Examples - GMX500, Intel wireless regulatory daemon. I think tightly integrated could do with some clarification here. qcserial was accepted despite not being functional without a closed userspace component - an open one's since been rewritten to allow it to work. Do we define tightly integrated as likely to cross the GPL line (potentially the case with Poulsbo, not the case with qcserial), or is it a pragmatic issue? What about specialised hardware drivers that only have closed applications? -- Matthew Garrett | mj...@srcf.ucam.org -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Mon, Jul 20, 2009 at 10:34:09PM +0200, Harald Welte wrote: On Sun, Jul 19, 2009 at 07:18:55PM +0200, Rafał Miłecki wrote: Did VIA consider cooperation with distributions? Maybe they could sponsor some single Mesa developers? What about The Linux Driver Project: http://linuxdriverproject.org/ ? Maybe they would like to cooperate? I'm looking for some solutions VIA could use without giving out a lot of money. How can a developer work on such a driver without sufficient documentation existing? Yes, with thousands of pages of actual manual (not just register dumps) you can do that. And yes, with access to the not-opensource-able driver, you can too. But without both? Very difficult. Both VIA and myself have a good relation to Greg K-H from the linux driver project. But how would we dare to ask somebody to help at a seemingly impossible task? I agree, the driver project does not take on things where we do not have full specifications. thanks, greg k-h -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug #13554] linux-image-2.6.30-1-686, KMS enabled: black screen, no X window
On Tue, 7 Jul 2009 02:00:46 +0200 (CEST) Rafael J. Wysocki r...@sisk.pl wrote: This message has been generated automatically as a part of a report of regressions introduced between 2.6.29 and 2.6.30. The following bug entry is on the current list of known regressions introduced between 2.6.29 and 2.6.30. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13554 Subject : linux-image-2.6.30-1-686, KMS enabled: black screen, no X window Submitter : Jos van Wolput wol...@onsneteindhoven.nl Date : 2009-06-17 06:28 (20 days old) Nico reported a black-screen regression too. Subject: 2.6.31-r2: Xorg: Black screen Compared to the other normal brightness problems, with 2.6.31-r2 xorg starts, but there is no image displayed (neither on internal nor external monitor). Switching back to console does not change the status, though hitting ctrlaltdel reboots the system (i.e. still up and running fine). It works with 2.6.30-rc7 (besides sometimes the brightness is broken there). This looks like it might be a post-2.6.30 regression, in which case it might have a separate cause. We're having a lot of problems in this area. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
2009/7/20 Thomas Hellström tho...@shipmail.org: Stephane, Some comments on how these things has been handled / could be handled. I would like to raise a couple of real-life issues I have in mind: * First example, let's say VIA gets their Chrome9 DRM merged into the kernel. Now let's say I reverse engineer the hardware (or use the docs whenever they're available) and write a 3D component that needs modifications to the existing DRM interface (or maybe I realize I need a completely new DRM). Then who gets the upper hand? Do I have to keep compatibility with user space binary modules that I do not care about? If there is a serious OS project, I'd start a new DRM driver. That's sort of what may happen with openChrome vs via.. Well, for user space, there can be as many drivers as you want for a given device. But the DRM policy always was one driver per hardware so as to avoid confusing people, so what you're proposing is in fact not possible. In that case, this would even deter a fully open source driver as it would have to keep the same interface as some (possibly unsupported) driver. * Second example, what is the policy if we find security holes in the DRM for a closed user-space afterwards? This breaks the initial promise of security, does that get the driver removed then? Or what if the promise is pending updated documentation that never arrives? I'd say the DRM driver gets disabled unless fixed. How would we handle that problem today with, for example, the SiS driver? If no one can fix it it gets killed, yes. I would expect this to happen pretty quickly in fact, in which case the driver merge/problem found/driver removal cycle requires more work than it's worth. * Third example, what if down the line we need changes in the DRM that require updating all DRM modules. Do we (we as in DRM developers) touch the DRM files for the VIA Chrome9 stuff, at the risk of breaking the code (since we don't test with proprietary modules)? Or do we let the Chrome9 files as-is, keeping the old DRM infrastructure and therefore add more and more DRM cruft? Again, this has been done quite commonly in the past and was easier to get right with the old drm.git testing ground. Same issue with unmaintained drivers with OS user-space. Who has actually tested all the drivers when making such a change? I certainly haven't. The change was left for testing for a while in drm.git before Dave moved it upstream. Well, some of us want to be thorough when doing invasive changes, untestable code would prevent such changes (and then we get more of the DRM cruft as a result). And yes, if people do not cooperate on all drivers, this leads to issues in the code. At this point it's not a matter of open source vs closed, but a problem of cooperation. Stephane -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
2009/7/21 Stephane Marchesin marche...@icps.u-strasbg.fr: 2009/7/20 Thomas Hellström tho...@shipmail.org: Stephane, Some comments on how these things has been handled / could be handled. I would like to raise a couple of real-life issues I have in mind: * First example, let's say VIA gets their Chrome9 DRM merged into the kernel. Now let's say I reverse engineer the hardware (or use the docs whenever they're available) and write a 3D component that needs modifications to the existing DRM interface (or maybe I realize I need a completely new DRM). Then who gets the upper hand? Do I have to keep compatibility with user space binary modules that I do not care about? If there is a serious OS project, I'd start a new DRM driver. That's sort of what may happen with openChrome vs via.. Well, for user space, there can be as many drivers as you want for a given device. But the DRM policy always was one driver per hardware so as to avoid confusing people, so what you're proposing is in fact not possible. In that case, this would even deter a fully open source driver as it would have to keep the same interface as some (possibly unsupported) driver. Well with KMS it sort of changes that a small bit, since a KMS driver really isn't required to share old interfaces, since having a KMS enabled kernel will break any userspace that is out there just by setting up the hw different. as long as the old code is still available in the backwards compat manner it should all be fine. We've also had two drm drivers before, i830 and i915 supported a lot of the same hw and it mostly worked, if you looked at it from a kernel perspective. Dave. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
I think tightly integrated could do with some clarification here. qcserial was accepted despite not being functional without a closed userspace component - an open one's since been rewritten to allow it to It got as far as staging with a good deal of complaint. I am not sure it would have gotten further unfixed (with my serial/tty maintainers hat on ;)). That however was about firmware - so a lot less tightly coupled. work. Do we define tightly integrated as likely to cross the GPL line (potentially the case with Poulsbo, not the case with qcserial), or is it a pragmatic issue? What about specialised hardware drivers that only have closed applications? Ultimately - ask a lawyer, ultimately this is a question about works and copyright boundaries. If the hardware has only some specific proprietary app then it sounds to me like it's not a general kernel interface so probably isn't a good interface anyway, let alone what the code may do. Alan -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Tue, Jul 21, 2009 at 12:28:35AM +0100, Alan Cox wrote: I think tightly integrated could do with some clarification here. qcserial was accepted despite not being functional without a closed userspace component - an open one's since been rewritten to allow it to It got as far as staging with a good deal of complaint. I am not sure it would have gotten further unfixed (with my serial/tty maintainers hat on ;)). That however was about firmware - so a lot less tightly coupled. ? It was merged directly into drivers/usb/serial. work. Do we define tightly integrated as likely to cross the GPL line (potentially the case with Poulsbo, not the case with qcserial), or is it a pragmatic issue? What about specialised hardware drivers that only have closed applications? Ultimately - ask a lawyer, ultimately this is a question about works and copyright boundaries. If the hardware has only some specific proprietary app then it sounds to me like it's not a general kernel interface so probably isn't a good interface anyway, let alone what the code may do. I was more wondering about whether we had issues with code that wasn't a GPL concern but still depended on a closed component. -- Matthew Garrett | mj...@srcf.ucam.org -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
2009/7/20 Greg KH gre...@suse.de: On Mon, Jul 20, 2009 at 10:34:09PM +0200, Harald Welte wrote: On Sun, Jul 19, 2009 at 07:18:55PM +0200, Rafał Miłecki wrote: Did VIA consider cooperation with distributions? Maybe they could sponsor some single Mesa developers? What about The Linux Driver Project: http://linuxdriverproject.org/ ? Maybe they would like to cooperate? I'm looking for some solutions VIA could use without giving out a lot of money. How can a developer work on such a driver without sufficient documentation existing? Yes, with thousands of pages of actual manual (not just register dumps) you can do that. And yes, with access to the not-opensource-able driver, you can too. But without both? Very difficult. Both VIA and myself have a good relation to Greg K-H from the linux driver project. But how would we dare to ask somebody to help at a seemingly impossible task? I agree, the driver project does not take on things where we do not have full specifications. AFAIU project accepts resources (documentation, code) under NDA. Can't VIA just give additional docs and/or code of current 3D driver with some explainations about parts that can't be published (all under NDA)? I'm not expert about all that, just trying to find way for VIA to get open source 3D driver. Forgive me if answer is obvious. -- Rafał Miłecki -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
