From: <bug...@fr...> - 2004-08-03 09:40:13
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://freedesktop.org/bugzilla/show_bug.cgi?id=943 mi...@da... changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|ei...@pd... |dri- | |de...@li... ------- Additional Comments From mi...@da... 2004-08-03 02:40 ------- Reassigning to dri-devel. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-01-04 15:36:41
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From da...@fr... 2005-01-04 07:36 ------- Comments? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-01-04 17:21:07
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From ei...@pd... 2005-01-04 09:21 ------- I expect that the code no longer applies to the current CVS version. I guess I need to port it again. Furthermore I was going to look into making the backward compatibility handling cleaner. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-01-04 22:08:26
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From ai...@fr... 2005-01-04 14:08 ------- The big issue is backwards compatiblity, this patch needs to be developed as two separate patches, one for the kernel, then tested with current X releases and submitted via the DRM tree, then one for Mesa and X that can also work with the old drm on normal systems (this isn't so important, you can get users to upgrade their kernel if they are upgrading X just use the DRM versioning, but upgrading your kernel should never break your X/DRI)... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-01-04 22:10:37
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From ai...@fr... 2005-01-04 14:10 ------- I also meant to say that if for some reason this is impossible, then these reasons should be raised with the kernel/X people and we find the solution that breaks the least number of working systems.... My belief at the moment (with no 64-bit machines to validate anything on) is that anything we do will probably break pure 64-bit clients, breaking pure 32-bit clients is of course completely unacceptable.... but maybe someone can find a way... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-01-13 15:09:36
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From kon...@gm... 2005-01-13 07:09 ------- Any updates on this yet ? A patch against the new drm would be fine. Greetings Jan -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-01-17 11:00:08
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From ei...@pd... 2005-01-17 03:00 ------- I haven't had time to do this, yet. It's on my list. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-03-03 09:21:11
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From pa...@sa... 2005-03-03 01:21 ------- Created an attachment (id=2011) --> (https://bugs.freedesktop.org/attachment.cgi?id=2011&action=view) Patch to add ioctl compatibility routines for 32-bit processes Here is my attempt at implementing ioctl compatibility routines for 32-bit processes on a 64-bit kernel. The patch is against a 2.6.11 Linux kernel tree. I have done the core DRM and the Radeon driver but not any of the other chipset drivers. I haven't changed the ABI, either for 32-bit or for 64-bit processes. I have used this successfully on a G5 powermac running a ppc64 Linux kernel, using unmodified 32-bit X server and client binaries. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-03-05 21:45:02
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 kon...@gm... changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kon...@gm... ------- Additional Comments From kon...@gm... 2005-03-05 13:44 ------- Hi i used the patch by Paul Mackerras on an x86-64 machine running Debian-Sid with Xorg from Ubuntu (with latest xorg-cvs ati drivers) and r300_driver from r300.sf.net. I tested it on an Pure ia32 setup and on my x86-64 setup. I tested with glxgears :) and neverball. It works for me in an pure ia32-setup, in an pure x86-64 setup. It also works when i boot an x86-64 kernel and chroot into my ia32-setup (as i think this is similiar to Pauls setup this was to be expspected). However when i boot into x86-64 and start and x86-64 Xserver and then chroot into my ia32-setup every gl-related operation (glxinfo, neverball ...) segfault. It would be nice, if i could start an x86-64 Xserver and use 32-bit gl-apps (as it is possible with fglrx), however currently i am very happy with the solution to stop my x86-64 Xserver, chroot into my ia32-setup and start the ia32 Xserver (as this was mostly missing using dri on x86-64). If you need more Information (eg on the segfault, or an patch against r300.sf.net drm sources or ...) feel free to ask. Thanks for your work. cheers Jan Kreuzer -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-03-06 10:37:44
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From kon...@gm... 2005-03-06 02:37 ------- Created an attachment (id=2024) --> (https://bugs.freedesktop.org/attachment.cgi?id=2024&action=view) dmesg from 64-bit kernel and Xserver and 32-bit glxinfo This is my dmesg output from an X86-64 kernel and Xserver and an ia32 chrooted glxinfo. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-03-06 10:40:08
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From kon...@gm... 2005-03-06 02:40 ------- Created an attachment (id=2025) --> (https://bugs.freedesktop.org/attachment.cgi?id=2025&action=view) strace from 32-bit glxinfo on 64-bit kernel and Xserver This is the strace from an chrooted ia32 glxinfo on an X86-64 Kernel and Xserver. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-03-08 07:40:02
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From pa...@sa... 2005-03-07 23:39 ------- Hmmm, presumably the X server is doing the addmap for the SAREA and then the client is mmapping it, but is using the wrong offset value. I see that the SAREA handle gets sent from the X server to the client in XF86DRIOpenConnection. I think the way to solve the problem is to always make a 32-bit handle for _DRM_SHM memory when CONFIG_COMPAT is defined, so that the X server will get a 32-bit handle for the SAREA even if it is a 64-bit process. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-03-24 08:53:39
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From ei...@pd... 2005-03-24 00:53 ------- > I think the way to solve the problem is to always make a 32-bit handle for > _DRM_SHM memory when CONFIG_COMPAT is defined, so that the X server will get a > 32-bit handle for the SAREA even if it is a 64-bit process. That's exactly what my code is doing. I've got an updated version of my patch that handles backward compatibility much more gracefully. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-04-09 13:52:59
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From ei...@pd... 2005-04-09 06:52 ------- In comment #11 Paul Mackerras writes: > I haven't changed the ABI, either for 32-bit or for 64-bit processes. I have > used this successfully on a G5 powermac running a ppc64 Linux kernel, using > unmodified 32-bit X server and client binaries. Unfortunately without a change in the ABI it is not possible to run 32bit DRI clients on 64 bit servers (or vice versa). The problem is that data structures shared between kernel, Xserver and clients have different sizes. However it is conceivable that users may want to run 32 and 64 applications on the same Xserver. With the reight defines the ioctl converters are very boiler plate. I'm going to attach an updated version of my patch. Presently I have support to the MGA, Radeon and Rage128 driver. The changes to DRM should be backward compatible so that unpatched Xservers and DRI libraries continue to work. Xserver, libGL and DRI drivers need to be updated together however. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-04-09 13:55:50
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ei...@pd... changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #541 is|0 |1 obsolete| | ------- Additional Comments From ei...@pd... 2005-04-09 06:55 ------- Created an attachment (id=2362) --> (https://bugs.freedesktop.org/attachment.cgi?id=2362&action=view) Updated patch (DRM part) This patch changes DRM so that 32bit DRI clients work on a 64bit kernel. It should be backward compatible to older versions of Xservers and client libraries. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-04-09 13:58:25
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From ei...@pd... 2005-04-09 06:58 ------- Created an attachment (id=2363) --> (https://bugs.freedesktop.org/attachment.cgi?id=2363&action=view) Fix for Mesa DRI drivers. This patch fixes the Mesa DRI drivers to support 32bit DRI clients on 64bit systems. It requires the patch in attachment #2362 and the Xserver patch that is going to be attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-04-09 14:01:51
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From ei...@pd... 2005-04-09 07:01 ------- Created an attachment (id=2364) --> (https://bugs.freedesktop.org/attachment.cgi?id=2364&action=view) Fix for Xserver part. This patch makes the required adjustments to the Xserver that are required when using attachment #2362 and #2363. The patch applies to a recent version of X.Org head. I have not bothered to apply all patches from #2363 to extra/Mesa also. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-04-10 02:48:56
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From pa...@sa... 2005-04-09 19:48 ------- I still don't see any reason why the ABI needs to be changed. The comment "data structures shared between kernel, Xserver and clients have different sizes" is too vague to be useful - which data structures, and what stops them being converted? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-04-11 18:55:18
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From ei...@pd... 2005-04-11 11:55 ------- > I still don't see any reason why the ABI needs to be changed. The comment > "data structures shared between kernel, Xserver and clients have different > sizes" is too vague to be useful - which data structures, and what stops them > being converted? Let me give you two examples: 1. mga_dri.h MGADRIRec is a data structure that is private to the Matrox DRI driver. It gets initialized in the DRI X driver. A DRI client (better to say the dri client module) can obtain this data structure from the Xserver thru the DRI extension request X_XF86DRIGetDeviceInfo. Usually X Request structures are carefully designed to be machine independent. Not in this case however: Since DRI assumes that communication happens locally it simply copies over the entire structure. If you look at the above structure it contains drmRegion elements. drmRegion contains a pointer and this is 32bit on a 32bit system or for a 32bit client on a 64bit system and 64bit if the binary is 64 bit. Therefore the last element of the MGADRIRec sarea_priv_offset comes at a different offset depending if your client is 32 or 64 bit. If you connect to a 64bit Xserver from a 32bit client your sarea_priv_offset value read by the client is probably wrong. Why should do the conversion? There is no way for the client to know if the structure has been sent by a 32bit or 64bit server. Also the server doesn't know what client is connected. (Only endianess information is transmitted in the X connection block). 2. The SAREA also contains a driver private structure (in case of the matrox driver contained in mga_sarea.h:MGASAREAPrivRec (drm: mga_drm.h:drm_mga_sarea_t). Its data is shared between the kernel and a DRI client. On 64bit systems it's conceivable that the kernel runs 64bit. How can the kernel and a DRI client share data thru a structure with different size? Converting the data structures of the ioctls is the easy part. You can simply write 'wrappers'. The only exception is where the kernel hands over 64bit 'handles' to user space which are used as offsets in mmap(). This doesn't work in 32bit user space. I've solved this problem without changing the ABI. However the handle is no real pointer any more which could cause issues to some drivers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-04-11 23:05:07
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From ai...@fr... 2005-04-11 16:05 ------- On the DRM portion can you look at the work Paul has done, it is much cleaner and less intrusive, you are also using the old method which is deprecated now in the kernel, the new method is available in Pauls patch in the -mm kernel, maybe Paul can generate a patch against 2.6.11.... My feeling on this now is that we should change to generating hashes for SHM handles for *all* platforms, having it different on 32 and 64 bits isn't going to help thing, make it break obviously for everyone and we'll find out if we can use this method or not ... I'd like to merge the DRM into the kernel and see who complains and maybe provide a command line option to fall back to the old 32-bit handle for 32-bit systems in case somebody breaks badly... I think between the two of you a clean solution should be possible, breaking the ABI between X and DRI clients isn't as bad as breaking the kernel/userspace boundard but I'd like to keep the 32-bit ABI the same if possible but I guess it might not be, I've no issues with telling someone to upgrade X and DRI at the same time from snapshots.. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-04-12 04:57:34
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From ai...@fr... 2005-04-11 21:57 ------- After a chat on IRC perhaps we can define a new DRIRec and just up the DDX numbers for the affected drivers.. then clients can know new/old DDX and either just use the new structure or do either of fail/fixup for the old structure depending on what they are running on. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-04-12 05:00:04
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From pa...@sa... 2005-04-11 21:59 ------- OK, Egbert is right concerning the server -> client communication. I ran across this with RADEONDRIRec. I checked all the SAREA definitions and they all seem to be OK, fortunately. It may be possible to convert in the client (based on the size of the structure received from the server) so that a new client can run with either a 32-bit or 64-bit server. Longer term I agree that changing the RADEONDRIRec and other structures to be wordsize-independent is a good idea. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-04-13 14:06:08
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From ei...@pd... 2005-04-13 07:06 ------- One could do a conversion - on the other hand a brakage of the ABI compatibility between client and Xserver would not be all that bad - given that we cannot really distinguish if a 32bit client library contains code that fixes the size or not. The main issue that I ran into was the size of drm_handle_t which I changed from 'long' to 'int'. It's defined in the drm headers however the drm modules don't seem to use it at all. It ensures that the same handles are used in 32 and 64bit and can be exchanged between 32 and 64bit pieces. This is done between the Xserver and 32bit clients. This however requires that 32 and 64bit both return 32bit handles. This may be the reason why my code is more intrusive. Apart from this of all the drivers I fixed I only saw an issue with Matrox. > On the DRM portion can you look at the work Paul has done, it is much cleaner > and less intrusive, you are also using the old method which is deprecated now > in > the kernel, the new method is available in Pauls patch in the -mm kernel, > maybe > Paul can generate a patch against 2.6.11.... The kernel ABI really hasn't changed. The ioctls have remained the same. The only change I've made was to make sure the handles passed between kernel and user space fit into 32bit. That means that they are not necessarily real offset values any more. If anything needs real offset values it needs to obtain it thru another way. If fit in 32bits my code attempts to reuse them. If they are 64bit however a 32bit hash is created. It is also make sure that the handles are unique. For your argument about intrusiveness please see above. I'm presently reworking my driver to support both the old and the new method. My intention was to make the creation of 32bit ioctls as boiler plate as possible. My hope was that this would encourage people to provide compat support for every driver. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-04-13 23:52:40
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From pa...@sa... 2005-04-13 16:52 ------- Created an attachment (id=2418) --> (https://bugs.freedesktop.org/attachment.cgi?id=2418&action=view) Patch for DRI client / X server compatibility This is what I am using at the moment, and with this, both 32-bit and 64-bit clients can connect to either a 32-bit or a 64-bit X server and do direct rendering. I have tested the r300 part of this patch on my G5. I have made the same changes to radeon and r200 and compile-tested them, but I don't have a 64-bit machine with a r100 or r200 graphics card. I agree that the drm_handle_t is the main problem. As for changing the interface, I think we should do that when the next reasonable opportunity arises. But for now, something like this would let us fix the 32/64 problem without breaking anything that currently works. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-04-13 23:58:36
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 ------- Additional Comments From pa...@sa... 2005-04-13 16:58 ------- A comment w.r.t. generating hashed handles: there are some cases where the radeon family of client-side DRI drivers do arithmetic to generate handles. I *think* this is only for AGP memory. I have a suspicion that the X server may also generate handles for the registers and/or the framebuffer by reading the device's PCI bus address registers, but I would need to verify that. Anyway, the point is that the handles can't be completely arbitrary for all types of mappings, at least not without checking a lot of code... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |