Re: From Eric Anholt:
> > Or is the installed 64-bit user base small enough that we > > can make them take one for the team, so to speak? > > With cheap 64-bit processors coming out from AMD and > Intel the base is growing faster than ever, so better > get on with it yesterday :) > > --j > with that in mind I'll try and generate a first patch in the next week or so, am boat diving for a few days but once I return I'll post a patch... Dave. > > > --- > This SF.Net email is sponsored by: SourceForge.net Broadband > Sign-up now for SourceForge Broadband and get the fastest > 6.0/768 connection for only $19.95/mo for the first 3 months! > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: From Eric Anholt:
On Wed, 12 May 2004, Ian Romanick wrote: > Or is the installed 64-bit user base small enough that we > can make them take one for the team, so to speak? With cheap 64-bit processors coming out from AMD and Intel the base is growing faster than ever, so better get on with it yesterday :) --j --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
Around 9 o'clock on May 12, Keith Whitwell wrote: > My one worry about the discussion is that because of confusion over where the > X developers are hanging out nowadays, they are missing out on having their > say on this - and they probably care deeply about modesetting. Egbert and I are here; I'm not sure who else wants to be involved at this point. I know I'm hoping that a great deal of the mode setting logic disappears from my piece of the system soon. -keith pgp0.pgp Description: PGP signature
Re: From Eric Anholt:
On Tue, 2004-05-11 at 16:34, [EMAIL PROTECTED] wrote: > On Wed, 12 May 2004 00:20:51 BST, Dave Airlie said: > > > I just looked at drm.h and nearly all the ioctls use int, this file is > > included in user-space applications also at the moment, I'm worried > > changing all ints to __u32 will break some of these, anyone on DRI list > > care to comment? > > Is this a case where somebody is *really* including kernel headers in userspace > and we need to smack them, or are they using a copy that's been sanitized > (and possibly fixed)? These headers being discussed are what define the interface between userland and kernel, and nothing else. They are included by both userland (libdrm, statically linked in the 3d drivers and in the X server) and kernel. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
--- Alan Cox <[EMAIL PROTECTED]> wrote: > argument for _good_ console support becomes that after boot you run a > graphical user space console app built with OpenGL, antialiased true When I proposed this a couple of months back both you and Linus called me insane. I need to go find those posts. This logical conclusion at the end of this is a user space console. It makes the problem of multi-user Linux simple to implement. Via OpenGL you also get full acceleration. If it is coordinated with xserver you can make your VT's appear as windows. There is still a master kernel based console that handles boot, printk, oops and kdbg. Each head will use the kernel based console to implement SAK. Ctrl-Alt-Del gets you SAK, SysReq get you the kernel console. No logins on the kernel console it is write only, SAK will start the user space console. The kernel console and SAK display are implemented in the driver. The trick to understanding this is that you have to understand the concept of how direct rendering works. With direct rendering there is no requirement to send everything to another process or the kernel. You can if you want, but you don't have to. --- Alan Cox <[EMAIL PROTECTED]> wrote: > On Maw, 2004-05-11 at 19:48, Egbert Eich wrote: > > For the text console to be usable you possibly want to be able to > > 1. move the fb start address for scrolling > > 2. to do some basik 2D accel for fast text drawing > > I thought about this a bit more. Let me propose a different viewpoint as > a result. That viewpoint is that there is no reason for any > acceleration. Scroll at most. > > If the video mode switching is done right and apps can handle graphics > nicely then you need a kernel mode text console at boot, but thinking > about Jon's ideas and the GL without X and other work the rational > argument for _good_ console support becomes that after boot you run a > graphical user space console app built with OpenGL, antialiased true > type font handling, megabyte scrollback, hotkeys, URL detection/menus, > googlizer and the like. > > On that basis the kernel driver really can be argued to be boot/debug > only. > > > > --- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to > deliver higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > ___ > Mesa3d-dev mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tests/blendminmax fails on r200
Ian Romanick wrote:
Roland Scheidegger wrote:
Ah, missed that in the spec. Seems to be unnecessarily restrictive
to not have a weighting factor for GL_MIN/MAX, apparently common
hardware could do it just fine (or maybe it doesn't make enough
sense to allow it?).
Modern hardware can, but that extension is almost 10 years old. I
don't think hardware was quite as orthogonal back then. :)
Here's a patch. That << 8 is a bit ugly, though. Should I add the
unshifted blend func values to r200_reg.h, together with some proper
defined shifts? I like the blend func value selection better than before
(where there was a huge function where the second half is (almost)
identical to the first). Fixes blendminmax indeed...
This does not explain though why the results are wrong if blending
isn't enabled in the first place, since neither blend function nor
blend equation should change anything if blending is disabled, I
think.
Yeah, that's probably a different problem. :( The r200 may not have
a way to actually disable blending. It might be that the hardware
has to be set to an equation of GL_ADD and functions of GL_ONE and
GL_ZERO. Dunno.
I've looked into it a bit further, it's strange. That
R200_ENABLE_ALPHA_BLEND surely DOES something, but not quite what I'd
expect. It doesn't affect the "logic op blending" (which is not
unexpected probably), and not enabling it indeed seems to prevent actual
blending calculations. But, if GL_MIN and GL_FUNC_REVERSE_SUBTRACT
blending functions are used, the result seems to be always 0 (black) in
that case. Odd.
Someone (maybe with documentation) has any ideas?
If not I'll try Ian's suggestion and basically just set it back to the
default blend func/equation whenever blending gets disabled (needs of
course other minor code modifications).
Roland
Index: r200_state.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_state.c,v
retrieving revision 1.18
diff -u -r1.18 r200_state.c
--- r200_state.c21 Mar 2004 17:05:03 - 1.18
+++ r200_state.c13 May 2004 00:19:29 -
@@ -104,156 +104,146 @@
rmesa->hw.ctx.cmd[CTX_PP_MISC] = pp_misc;
}
-static void r200BlendEquationSeparate( GLcontext *ctx,
- GLenum modeRGB, GLenum modeA )
-{
- r200ContextPtr rmesa = R200_CONTEXT(ctx);
- GLuint b = rmesa->hw.ctx.cmd[CTX_RB3D_BLENDCNTL] & ~R200_COMB_FCN_MASK;
-
- assert( modeRGB == modeA );
-
- switch ( modeRGB ) {
- case GL_FUNC_ADD:
- case GL_LOGIC_OP:
- b |= R200_COMB_FCN_ADD_CLAMP;
- break;
-
- case GL_FUNC_SUBTRACT:
- b |= R200_COMB_FCN_SUB_CLAMP;
- break;
-
- case GL_FUNC_REVERSE_SUBTRACT:
- b |= R200_COMB_FCN_RSUB_CLAMP;
- break;
-
- case GL_MIN:
- b |= R200_COMB_FCN_MIN;
- break;
-
- case GL_MAX:
- b |= R200_COMB_FCN_MAX;
- break;
-
- default:
- break;
- }
-
- R200_STATECHANGE( rmesa, ctx );
- rmesa->hw.ctx.cmd[CTX_RB3D_BLENDCNTL] = b;
- if ( ctx->Color._LogicOpEnabled ) {
- rmesa->hw.ctx.cmd[CTX_RB3D_CNTL] |= R200_ROP_ENABLE;
- } else {
- rmesa->hw.ctx.cmd[CTX_RB3D_CNTL] &= ~R200_ROP_ENABLE;
- }
-}
-
-static void r200BlendFuncSeparate( GLcontext *ctx,
-GLenum sfactorRGB, GLenum dfactorRGB,
-GLenum sfactorA, GLenum dfactorA )
+/**
+ * Calculate the hardware blend factor setting. This same function is used
+ * for source and destination of both alpha and RGB.
+ *
+ * \returns
+ * The hardware register value for the specified blend factor. This value
+ * is already shifted for source factor, but needs to be reshifted for
+ * destination factor.
+ *
+ * \todo
+ * Since the two cases where source and destination are handled differently
+ * are essentially error cases, they should never happen. Determine if these
+ * cases can be removed.
+ */
+static int blend_factor( GLenum factor, GLboolean is_src )
{
- r200ContextPtr rmesa = R200_CONTEXT(ctx);
- GLuint b = rmesa->hw.ctx.cmd[CTX_RB3D_BLENDCNTL] &
- ~(R200_SRC_BLEND_MASK | R200_DST_BLEND_MASK);
+ int func;
- switch ( ctx->Color.BlendSrcRGB ) {
+ switch ( factor ) {
case GL_ZERO:
- b |= R200_SRC_BLEND_GL_ZERO;
+ func = R200_SRC_BLEND_GL_ZERO;
break;
case GL_ONE:
- b |= R200_SRC_BLEND_GL_ONE;
+ func = R200_SRC_BLEND_GL_ONE;
break;
case GL_DST_COLOR:
- b |= R200_SRC_BLEND_GL_DST_COLOR;
+ func = R200_SRC_BLEND_GL_DST_COLOR;
break;
case GL_ONE_MINUS_DST_COLOR:
- b |= R200_SRC_BLEND_GL_ONE_MINUS_DST_COLOR;
+ func = R200_SRC_BLEND_GL_ONE_MINUS_DST_COLOR;
break;
case GL_SRC_COLOR:
- b |= R200_SRC_BLEND_GL_SRC_COLOR;
+ func = R200_SRC_BLEND_GL_SRC_COLOR;
break;
case GL_ONE_MINUS_SRC_COLOR:
- b |= R200_SRC_BLEND_GL_ONE_MINUS_SRC_COLOR;
+ func = R200_SRC_BLEND_GL_ONE_MINUS_SRC_COLOR;
break;
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
cvs -d:[EMAIL PROTECTED]:/cvs/mesa co drm it is in the video reset directory. you will need to modify it a little for command line use since it is meant to be called from a hotplug event --- Richard Smith <[EMAIL PROTECTED]> wrote: > Jon Smirl wrote: > > > licenses). I've already built a very messy prototype by moving the existing > > fbdev code to user space and it works just fine. I also called another > little > > app which executed the VBIOS and reset secondary cards at boot via hotplug. > > Is that app available somewhere? I'm trying to get an ATI Rage Mobility > M1 chip up under LinuxBIOS and such and app would be useful for me. > > > > > --- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to > deliver higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: From Eric Anholt:
> is the installed 64-bit user base small enough that we can make them take one > for the team, so to speak? yeah I'm getting the feeling a flag day may be necessary --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Yet another discussion on fbcon and dri
Hey all, I've been following the discussion on driver simplification, and I'm not quite sure I understand everything that has been said. As I understand it, you are trying to make kernel drivers just init the hardware, and provide hooks for userspace software to drive the hardware themselves? (ie, fbcon and dri get merged, and the kernel driver just provides video mode switching, video memory management, state management, and enough access for dri-userland to do everything else) If this is right, is there any way to provide an easy and well thoughtout framework? Like, fbcon drivers have the bad habit of not having the same method of telling them what modes to use. (Some only work with vga=, some only work with mode=, and some (correctly) use modedb (like they should)); and X does a lot of hardware poking when it shouldn't, and X drives a lot of the 2D stuff itself, when it really should be using the fbcon driver's abilities as much as possible (which probably arn't properly exposed (which I bet is pissing off a lot of directfb devs)) Thanks in advance -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 signature.asc Description: Digital signature
Re: From Eric Anholt:
Linus Torvalds wrote: On Wed, 12 May 2004, Dave Airlie wrote: I just looked at drm.h and nearly all the ioctls use int, this file is included in user-space applications also at the moment, I'm worried changing all ints to __u32 will break some of these, anyone on DRI list care to comment? Right now, all architectures have "int" being 32-bit, so nothing should break. Apart from sign issues, of course. If there are pointers and "long", then those should just not exist. Never expose kernel pointers to user mode (and you really never should pass user pointers back), and "long" should really just be "__u32" instead (since that is what it is on a 32-bit platform - and if it works there, then it should work on a 64-bit platform too). Right. We came to that same conclusion when this issue came up a year ago. The problem, and I suspect the reason nothing happened, is that we have a potential binary compatibility problem. As a concrete example, if we change all instances of "unsigned long" to __u32, user-mode drivers built to that interface will break with currently installed DRM drivers on all 64-bit platforms. At the same time, on "pure" 64-bit platforms (like Alpha), changing (only) the kernel will also break things. That makes this a case where bumping the DRM interface version number won't even help. :( Clearly leaving things as they are is not viable. Going through and doing s/unsigned long/__u32/g isn't much better. Anyone have a 3rd option? :( Or is the installed 64-bit user base small enough that we can make them take one for the team, so to speak? --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
> What this is saying is that very early in the boot process the graphics driver > will be initialized. At this point it will generate a hotplug event. This event > will be handled by an app and lib that live in initramfs. This is not saying > that mode-setting will be delayed until normal user space starts. The initial > hotplug event occurs very early in the boot process, almost as early as the > current device driver based code runs. Right now alot of application including commerical depend on setting the video mode via /dev/fb. I like to have /sys do that in the future. If that goes away it will break alot of software. Hurt alot of companies. Now consider these apps in the future and how with the above will work. app -> /dev/fb to change mode -> context switch to kernel -> send hot plug event -> userland app grabs event -> loads library to execute the code if it hasn't done so already -> set mode in userland library -> via a ioctl creates a event packet to send back to kernel to let them know it worked. Also we need to send back detail data on the new mode for the app. We might of not got the exact mode we wanted so we send back the closes thing we wanted. -> context switch to kernel -> store new data kernel side. -> call library to grab new resolution data for a app. Now you could say we could remove the fbdev interface completely and move to the library. But then you have the below case. Now consider the case of a VC switch where two VC's are at different resolutions. Say one is at 80x30 and the other is 128x48 You press Alt-Fx -> VT code call console_callback -> send a hotplug event to userland -> a userland app gets the event -> loads the userland library -> executes the code to set the video mode -> send back a ok from userland. Again we need to send a packet back to kernel to let them know if it was successful. Also we need to let them know the exact details of the mode we actually got. -> context switch to kernel -> write new data to struct vc_data. This is a really expensive solution. I understand you point of the mode switching code being huge. The embedded guys require really lean kernels. I have no problem making the mode switching code modular. I just want to avoid the above overhead. > This is very similar to the way udev works. Udev is a user space replacement for > devfs. Instead of having a /dev with 40,000 devices in it, udev builds one on > the fly at each boot with exactly your devices in it. Now that I have used udev > instead of devfs I have to agree that it is a much better solution. In fact the > udev app will run before the mode-setting app since it's the udev app that > creates the devices in /dev now by detecting additions to sysfs. udev FAQ: > http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ > We all know Linux is non-functional without a /dev directory, and now /dev is > being build in user space. I also like udev much more than devfs. The difference is that userland doesn't modify device nodes. You create them and you remove them. Very basic. Fbdev is a bit more complex than that. You can see that in the above arguments. > Andrew, akpm, has also explained to me that even the current fbdev is not > really active at boot. Instead those initial printk's are queued until > the fbdev driver initialized and prints them. That is true and I consider it a bug. The true is that the fbdev layer could be started right away for most of the drivers. Most fbdev devices are embedded devices which don't need a bus initialized first. Even on intel you could have the vga16 driver started at the exact same time as vgacon. The limitation is only for devices like pci. Personally I like to see fbcon start at the same time as vgacon and the rest and if the graphics card is pci then when it initializes then start drawing the data. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
> > That app must be pretty big if it runs on non intel platforms. You nedd to > > translate the x86 BIOS code to native assembly before you run it. > > Or interprete it. Only if we could use Java for the video BIOS. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
On Wed, 12 May 2004, James Simmons wrote:
> I understand you point of the mode switching code being huge. The embedded
> guys require really lean kernels. I have no problem making the mode switching
> code modular. I just want to avoid the above overhead.
And for an embedded device with a fixed LCD screen you can easily make the mode
setting code __init, and disallow mode changes after boot up. One device
driver, just one more kernel config option. Some code has to do the mode
setting anyway, so better keep it in one place.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
> Anyway. I've got a lot of respect for the people involved in the discussion, > even when they hold quite conflicting views, so I'm hopeful that some sort of > direction can be reached for moving forward. I apologize for getting over heated. I'm very protective of the companies that work in the embedded space. I don't want to see them go away. They are vitial to linux. I know this might get some people upset but IMNSHO the linux community is going after the wrong goal. Everyone keeps thinking desktop PC. We don't have the resources to win that war and second the PC is NOT the future. I work for a asian company and when you go to the asian rim you see that the latest technology is in the embedded space. Look all around you. Embedded devices are everywhere. In stoplights, cars, supermarkets, tv, dvd players. Next time you use your printer look at the little display. Guess what? That printer is most likely a linux box and that little display is a framebuffer devices. How do I know? Because I wrote that code for the last company I worked at. For the embedded space we do have the resources to win that area of the market if we provide the tools they need to succeed. What do most people use there laptops for. Mostly playing movies. I also see embedded devices coming to this market soon that do the same thing for alot less money. Even the 3D graphics market is moving away from the PC to game consoles. > My one worry about the discussion is that because of confusion over where the > X developers are hanging out nowadays, they are missing out on having their > say on this - and they probably care deeply about modesetting. Though, given > the mad flamewar it's turned into, maybe smaller is better... Sorry about the flamewar. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
On Wed, 12 May 2004, James Simmons wrote:
> > > That app must be pretty big if it runs on non intel platforms. You nedd to
> > > translate the x86 BIOS code to native assembly before you run it.
> >
> > Or interprete it.
>
> Only if we could use Java for the video BIOS.
Java? em86 (written by Gabriel Paubert) has been working fine on my PPC box
since 1998.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
On Wed, 12 May 2004, James Simmons wrote:
> That app must be pretty big if it runs on non intel platforms. You nedd to
> translate the x86 BIOS code to native assembly before you run it.
Or interprete it.
> On Wed, 12 May 2004, Richard Smith wrote:
> > Jon Smirl wrote:
> > > licenses). I've already built a very messy prototype by moving the existing
> > > fbdev code to user space and it works just fine. I also called another little
> > > app which executed the VBIOS and reset secondary cards at boot via hotplug.
> >
> > Is that app available somewhere? I'm trying to get an ATI Rage Mobility
> > M1 chip up under LinuxBIOS and such and app would be useful for me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
Alan Cox writes: > > In which case bank switch is needed. Its actually not clear you need > 2D accel. Its *nice* but not essential. Its becoming more and more the > case that console mode is the debug/boot interface for a device. OK. > > > (I'n not talking about > > VGA banking, but it seems like modern HW may not be able to map in all video > > memory at the same time). > > We hit this with the vesa driver - we just use the first 8Mb or so > nowdays. That should work. The kernel could use whatever bank is currently mapped. Or the banking is done inside the kernel - as it may be needed anyway to do DRI. Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
> > > > That app must be pretty big if it runs on non intel platforms. You nedd to > > > > translate the x86 BIOS code to native assembly before you run it. > > > > > > Or interprete it. > > > > Only if we could use Java for the video BIOS. > > Java? em86 (written by Gabriel Paubert) has been working fine on my PPC box > since 1998. It was a joke. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
James Simmons wrote: That app must be pretty big if it runs on non intel platforms. You nedd to translate the x86 BIOS code to native assembly before you run it. Or you emulate thier functionality.. but perhaps thats what you are saying. Thats what X does. LinuxBIOS has pulled the x86emu out into a standalone userspace app that we use to try and get video cards up across a serial console. Currently that app is 400k (dynamic linked) The plan though is to include that emulation ability into LinuxBIOS and 400k is way to large. The authors feel though that it can be done. I think the core pieces aren't really that big. It dosen't seem to work with my ATI bios though which is why I was interested in another implementation. Word is that the current LinuxBIOS implementation has issues with int10 replacement and then calling back into itself. Jon Smirl wrote: licenses). I've already built a very messy prototype by moving the existing fbdev code to user space and it works just fine. I also called another little app which executed the VBIOS and reset secondary cards at boot via hotplug. Is that app available somewhere? I'm trying to get an ATI Rage Mobility M1 chip up under LinuxBIOS and such and app would be useful for me. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
That app must be pretty big if it runs on non intel platforms. You nedd to translate the x86 BIOS code to native assembly before you run it. On Wed, 12 May 2004, Richard Smith wrote: > Jon Smirl wrote: > > > licenses). I've already built a very messy prototype by moving the existing > > fbdev code to user space and it works just fine. I also called another little > > app which executed the VBIOS and reset secondary cards at boot via hotplug. > > Is that app available somewhere? I'm trying to get an ATI Rage Mobility > M1 chip up under LinuxBIOS and such and app would be useful for me. > > > > > --- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to > deliver higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > ___ > Linux-fbdev-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
On Tue, May 11, 2004 at 08:30:45PM -0700, Jon Smirl wrote: [...] > So moving mode setting to user space is not the end of the world. Everything > will still work. This is more like a monolithic vs microkernel type of decision. Which is why Linux is a monolithic kernel, it's by design. The net is plenty of linus' threads about this. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] http://www.freebsd.org/~nsouch/kgi4BSD --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: From Eric Anholt:
On Wed, 12 May 2004, Dave Airlie wrote: > > I just looked at drm.h and nearly all the ioctls use int, this file is > included in user-space applications also at the moment, I'm worried > changing all ints to __u32 will break some of these, anyone on DRI list > care to comment? Right now, all architectures have "int" being 32-bit, so nothing should break. Apart from sign issues, of course. If there are pointers and "long", then those should just not exist. Never expose kernel pointers to user mode (and you really never should pass user pointers back), and "long" should really just be "__u32" instead (since that is what it is on a 32-bit platform - and if it works there, then it should work on a 64-bit platform too). Linus --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM v1.3 under 2.4.24-epia PCI changes?
Hi, Getting there with the process of getting all the VIA stuff working. Using 2.4.24-epia1 kernel and XF86 4.4, and got X working with the VIA driver as below. XFree86 Version 4.4.0 Release Date: 29 February 2004 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.24-epia1 i686 [ELF] Current Operating System: Linux jukebox1 2.4.24-epia1 #15 Wed May 12 09:15:13 EDT 2004 i686 Build Date: 11 May 2004 II) VIA(0): initializing int10 (II) VIA(0): Primary V_BIOS segment is: 0xc000 (II) VIA(0): VESA BIOS detected (II) VIA(0): VESA VBE Version 3.0 (II) VIA(0): VESA VBE Total Mem: 32768 kB (II) VIA(0): VESA VBE OEM: VIA CLE266 To get XvMC I grabbed the latest DRM 1.3 due to. (EE) VIA(0): [XvMC] Kernel drm is not compatible with XvMC. (EE) VIA(0): [XvMC] Kernel drm version: 1.1.0 and need at least version 1.3.0. However with the build of DRM I get the following: drm_drv.h: In function `drm_init': drm_drv.h:708: warning: implicit declaration of function `pci_get_subsys' drm_drv.h:708: warning: assignment makes pointer from integer without a cast drm_drv.h:718: warning: implicit declaration of function `pci_dev_put' I pulled the DRM source from CVS and am trying to build standalone. Anybody any suggestions for this? Is the DRM update and VIA drivers all included in the Unichrome source RPM? Wondering which methodology get over this final problem?Thank you very much in advance. A
Re: tests/blendminmax fails on r200
Roland Scheidegger wrote: Ian Romanick wrote: Roland Scheidegger wrote: this new demo fails pretty horribly on r200. It seems to be caused by the same bug as I reported here, http://marc.theaimsgroup.com/?l=dri-devel&m=107854279829216&w=2, something fundamental just doesn't work right with regard to blending. Even if you never enable blending (or disable it explicitly) in this blendminmax demo, the results are vastly different to software rendering (blend equation seems to make a difference even if blending is disabled for some reason). You beat me to the punch. :) When I wrote that test I was 99% sure it would fail on R200 the same way it failed on i830. The problem is that the GL_MIN and GL_MAX modes do *NOT* use the values set by glBlendFunc (or glBlendFuncSeparate). If the blend equation is set to GL_MIN or GL_MAX, it is supposed to operate as if 'glBlendFunc(GL_ONE,GL_ONE)' was set. Ah, missed that in the spec. Seems to be unnecessarily restrictive to not have a weighting factor for GL_MIN/MAX, apparently common hardware could do it just fine (or maybe it doesn't make enough sense to allow it?). Modern hardware can, but that extension is almost 10 years old. I don't think hardware was quite as orthogonal back then. :) This does not explain though why the results are wrong if blending isn't enabled in the first place, since neither blend function nor blend equation should change anything if blending is disabled, I think. Yeah, that's probably a different problem. :( The r200 may not have a way to actually disable blending. It might be that the hardware has to be set to an equation of GL_ADD and functions of GL_ONE and GL_ZERO. Dunno. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[r200] sigfault in update_light (current DRI and Mesa CVS)
SunWave1 progs/demos# ./gears Mesa: software DXTn compression/decompression available Speicherschutzverletzung (core dumped) Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Loaded symbols for /usr/X11R6/lib/libXt.so.6 Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...done. Loaded symbols for /usr/X11R6/lib/modules/dri/r200_dri.so Reading symbols from /usr/lib/libtxc_dxtn.so...done. Loaded symbols for /usr/lib/libtxc_dxtn.so #0 0x406d2369 in update_light () from /usr/X11R6/lib/modules/dri/r200_dri.so (gdb) info registers eax0x81ebf38136232760 ecx0x805b600134592000 edx0x81ebf50136232784 ebx0x805bce8134593768 esp0xbfffeba0 0xbfffeba0 ebp0x805b6000x805b600 esi0x805e9a0134605216 edi0x81ebf47136232775 eip0x406d2369 0x406d2369 eflags 0x10202 66050 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) bt #0 0x406d2369 in update_light () from /usr/X11R6/lib/modules/dri/r200_dri.so #1 0x0805e9a0 in ?? () #2 0x01084440 in ?? () Sorry no more time today ;-) -Dieter --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Memory management of AGP and VRAM
On Mer, 2004-05-12 at 20:04, Sottek, Matthew J wrote: > >On that basis the kernel driver really can be argued to be boot/debug > >only. > > I don't see this leap? Unclear on my part sorry - I was just referring to the text-mode console bits not the entire system --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tests/blendminmax fails on r200
Ian Romanick wrote: Roland Scheidegger wrote: this new demo fails pretty horribly on r200. It seems to be caused by the same bug as I reported here, http://marc.theaimsgroup.com/?l=dri-devel&m=107854279829216&w=2, something fundamental just doesn't work right with regard to blending. Even if you never enable blending (or disable it explicitly) in this blendminmax demo, the results are vastly different to software rendering (blend equation seems to make a difference even if blending is disabled for some reason). You beat me to the punch. :) When I wrote that test I was 99% sure it would fail on R200 the same way it failed on i830. The problem is that the GL_MIN and GL_MAX modes do *NOT* use the values set by glBlendFunc (or glBlendFuncSeparate). If the blend equation is set to GL_MIN or GL_MAX, it is supposed to operate as if 'glBlendFunc(GL_ONE,GL_ONE)' was set. Ah, missed that in the spec. Seems to be unnecessarily restrictive to not have a weighting factor for GL_MIN/MAX, apparently common hardware could do it just fine (or maybe it doesn't make enough sense to allow it?). This does not explain though why the results are wrong if blending isn't enabled in the first place, since neither blend function nor blend equation should change anything if blending is disabled, I think. Roland --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Memory management of AGP and VRAM
>I thought about this a bit more. Let me propose a different viewpoint as >a result. That viewpoint is that there is no reason for any >acceleration. Scroll at most. > >If the video mode switching is done right and apps can handle graphics >nicely then you need a kernel mode text console at boot, but thinking >about Jon's ideas and the GL without X and other work the rational >argument for _good_ console support becomes that after boot you run a >graphical user space console app built with OpenGL, antialiased true >type font handling, megabyte scrollback, hotkeys, URL detection/menus, >googlizer and the like. > I agree! The 99% case should just be a user-space console. It is a much more efficient design because currently the console renders rather synchronous with the data being generated which is unnecessary. but back to the banked memory problem. The issue is that writing pixels is a device dependent operation. Just because there are only a handful a ways it is done does not make it device independent. You should be calling a "put" function rather than drawing characters in memory from DI code. The put function's implementation would probably be to call a generic helper but any implementation could be used. The kernel-proper then never draws to memory directly. This also allows any locking or hardware idling to be done transparently in the driver where it belongs. Yes, there is a speed disadvantage but if we are going toward doing 99% of console drawing from a user-space client it is not a concern. >On that basis the kernel driver really can be argued to be boot/debug >only. I don't see this leap? Hardware touching still needs a privileged home. That is either a *.so linked to a root app, A root daemon, or a kernel driver. (perhaps you meant the kernel-proper->driver interface is only used for boot/debug) I still think the solution is user-space API backed by whatever the driver writer wants/needs. My prediction is that you end up with some small kernel driver doing the hardware touching with a thin DD user-space API called from a corresponding DD layer within OGL, X server, whatever. So I think we are jelling around this concept. (Speak up if this doesn't jell with you) 1: A user mode library interface for basic mode setting that does not require elevated privileges. library is backed by whatever technical means suits your fancy. 2: Some optional components to the mode setting interface to deal with some more advanced but still device independent concepts. 3: Any number of device dependent interfaces. 4:A kernel level API so that the kernel-proper can draw in a device independent manner for slow consoles, oopsen, debuggers, and booting. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tests/blendminmax fails on r200
Roland Scheidegger wrote: this new demo fails pretty horribly on r200. It seems to be caused by the same bug as I reported here, http://marc.theaimsgroup.com/?l=dri-devel&m=107854279829216&w=2, something fundamental just doesn't work right with regard to blending. Even if you never enable blending (or disable it explicitly) in this blendminmax demo, the results are vastly different to software rendering (blend equation seems to make a difference even if blending is disabled for some reason). You beat me to the punch. :) When I wrote that test I was 99% sure it would fail on R200 the same way it failed on i830. The problem is that the GL_MIN and GL_MAX modes do *NOT* use the values set by glBlendFunc (or glBlendFuncSeparate). If the blend equation is set to GL_MIN or GL_MAX, it is supposed to operate as if 'glBlendFunc(GL_ONE,GL_ONE)' was set. This would be an ideal bug for a DRI newbie to fix. :) Take a look at the functions i830BlendFuncSeparate, i830BlendEquationSeparate, and i830_set_blend_state (all in i830_state.c) for some guidance. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
On Maw, 2004-05-11 at 19:48, Egbert Eich wrote: > For the text console to be usable you possibly want to be able to > 1. move the fb start address for scrolling > 2. to do some basik 2D accel for fast text drawing I thought about this a bit more. Let me propose a different viewpoint as a result. That viewpoint is that there is no reason for any acceleration. Scroll at most. If the video mode switching is done right and apps can handle graphics nicely then you need a kernel mode text console at boot, but thinking about Jon's ideas and the GL without X and other work the rational argument for _good_ console support becomes that after boot you run a graphical user space console app built with OpenGL, antialiased true type font handling, megabyte scrollback, hotkeys, URL detection/menus, googlizer and the like. On that basis the kernel driver really can be argued to be boot/debug only. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
On Maw, 2004-05-11 at 19:48, Egbert Eich wrote: > For the text console to be usable you possibly want to be able to > 1. move the fb start address for scrolling > 2. to do some basik 2D accel for fast text drawing > > Also your framebuffer may not be completely linear. In which case bank switch is needed. Its actually not clear you need 2D accel. Its *nice* but not essential. Its becoming more and more the case that console mode is the debug/boot interface for a device. > (I'n not talking about > VGA banking, but it seems like modern HW may not be able to map in all video > memory at the same time). We hit this with the vesa driver - we just use the first 8Mb or so nowdays. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Current discussion about the future of free software graphics
On Maw, 2004-05-11 at 20:55, James Simmons wrote: > Ug. I see I'm fighting a losing battle but it doesn't matter. I couldn't > never win this fight. There is MONEY involved here. This is a sure way > to make sure Tungstengraphics has a income coming in. They want a monoply > on the linux graphics arena then fine they can have it. Current DRI is certainly a PITA unless you know it well but the kernel side is quite trivial underneath the macrotrastrophe and preprocessor abuse. Its mappable buffers, queue, interrupt handler, X<->kernel auth mapping, and thats it Also I'd note several folks are doing DRI nowday without Tungsten - VIA did the Savage and VIA drivers, sis6326 is a WIP but its also not tungsten stuff. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
tests/blendminmax fails on r200
this new demo fails pretty horribly on r200. It seems to be caused by the same bug as I reported here, http://marc.theaimsgroup.com/?l=dri-devel&m=107854279829216&w=2, something fundamental just doesn't work right with regard to blending. Even if you never enable blending (or disable it explicitly) in this blendminmax demo, the results are vastly different to software rendering (blend equation seems to make a difference even if blending is disabled for some reason). Roland --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: From Eric Anholt:
Dave Airlie wrote: Ick, you can't use "int" as an ioctl structure member, sorry. Please use the proper "__u16" or "__u32" value instead. I just looked at drm.h and nearly all the ioctls use int, this file is included in user-space applications also at the moment, I'm worried changing all ints to __u32 will break some of these, anyone on DRI list care to comment? Yeah, this has been discussed before. Unfortunately, I think we collectively decided to bury our heads in the sand. :( http://marc.theaimsgroup.com/?l=dri-devel&m=104343303725014&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=104676626223226&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=105096939304023&w=2 And what about kernels running in 64bit mode with 32bit userspace? Care to provide the proper thunking layer for them too? --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Code clean up (remove compilation warning)
Jerome Glisse wrote: Sorry for cross posting but i got a little question :) DRI use the mesa cvs for a part of this drivers right now ? isn't it ? If so please review my patch that intend to correct compilation warning (most of my patch simply add type cast to avoid warning) For the DRI patch : I have done some cleaning in order to avoid warning during compilation. The attached patch correct some of these. Some of the casts look suspicious (the ones in i830_context.c and mach64_screen.c make me wonder if there's a problem elsewhere.) Maybe someone else can review those. The patch to tdfx_tex.c was incorrect; I've checked in the right fix. But in order to have even less warning some changes need to be discuss. First if we use -std=c99 with gcc we could get less warning ass some source use c99 standard (like macro with variables arguments count. (in src/mesa/drivers/dri/common/xmlconfig.c L400) Other use string lenght greater than 4095 (shader/arbprogparse.c L143, L3703) Thus i guess we should use std=c99 anyone around against this ? Or are they any issue with std=c99 that i am not aware of ? I'd have to tinker with std=c99 a bit myself to see if it's worthwhile. We already compile with a fairly good set of warning flags. In src/mesa/main/texstore.h there is strange code i may misunderstand : #if !NEWTEXTSTORE ...code... #endif Maybe we should have : #ifndef NEWTEXTSTORE ...code... #endif The NEWTEXSTORE stuff is obsolete. I've removed it. For the nurbs patch - Again this patch is for compilation warning i tried to correct as many as i can (i am still working on some of them as there are case where i need to go deeper in code in order to understand what is done to be sure to no broke the things =)) Thus my patch most of time put in comment unused variable or simply remove them when i think we could really remove them... The GLU code comes from SGI and I've never put too much effort into fixing warnings in that code. But I'll probably apply your patch after I review it closer. I guess warning are not the first things to worry about but right now this is the little i can do to help a bit :) More over having a code that compile without a warning is nice, isn't it ? =) By the way is there any plan to change the compiling scheme in mesa ? Using autoconf automake for checking if dependency exist like the drm source free or some x header or other stuff like that... We had autoconf/automake/libtool in Mesa in the past. It caused no end of problems so I dumped it. It seemed to seldom work on non-Linux systems. -Brian --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
Jon Smirl wrote: licenses). I've already built a very messy prototype by moving the existing fbdev code to user space and it works just fine. I also called another little app which executed the VBIOS and reset secondary cards at boot via hotplug. Is that app available somewhere? I'm trying to get an ATI Rage Mobility M1 chip up under LinuxBIOS and such and app would be useful for me. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
David Bronaugh writes: > Egbert Eich wrote: > > > >I don't think you want to call user mode code from inside the kernel. > >The kernel could take a passive role and use the mode that a userland > >program tells it is set. If all the kernel needs is a linear freambuffer > >of size x * y and depth d there is no problem. > >Things get a little more complicated if the kernel wants to set the fb > >start address for scrolling, use acceleration for faster drawing or the > >framebuffer is not really fully linear. > > > > > I was talking about the userspace code -only- doing mode setting. It > would take the parameters passed to it via a FIFO or whatever, in > whatever format, and set that mode on the specified device. Nothing more. > > It wouldn't have state (if at all possible). > > One thing I'm not at all sure about is how to have bidirectional > communication between kernel and userspace. The idea I had was for the > userspace mode-setting program to open a block device-file (like > /dev/drmctl0 (just making up names here)) and wait for input in the form > of a string (there's no reason to go with the formats I've suggested > here; they're just for the sake of argument). On receipt of that input, > it would either set the requested mode and tell the kernel exactly what > mode it set, or not set the requested mode and tell the kernel it didn't > set the mode (both via the same device-file; maybe an ioctl?). That is pretty much like power management is handled today. A user daemon sits there and waits for events. It will act accordingly and return a status to the kernel. But why do you want to do mode setting from inside the kernel anyhow? If we can make the kernel do its output on whatever video mode it gets we should be fine. This way the user app sets the video mode and the kernel can still print emergency messages (well, in theory - as writing to the fb will definitely collide with active accellerator hardware). And the initial mode setting for boot messages needs to happen way earlier - possibly in a bootstrap manager. > > > > As I see it, this'd basically get around all the license problems with > > > the mode setting code (it could still be GPL, yet since it isn't in a > > > position to taint, that's OK) and it would result in -one- location, > > > guaranteed, for mode setting code. I don't know whether the one location > > > thing'd be a good idea, but it sounds like one to me. > > > >Here my point is that the world is not Linux only (although I use Linux > >myself) and it would make sense to make this code portable across OSes. > >In this case GPL may be a problem - especially if the code needs to > >go into the kernel. > > > > > The userspace mode-setting program (what I'm talking about here), which > would be doing any more tricky mode setting, would have -no- hooks into > the kernel. None. Thus, even if it were GPL, it wouldn't be a problem > for it to be running on a *BSD. > > > > It'd ensure that the mode setting code was -entirely- separate from the > > > X server, any other libraries, etc. It'd also allow the driver writer, > > > at their discretion, to put the code in the kernel (in which case the > > > userspace code would never be used) or in userspace (in which case the > > > kernel would simply request that the userspace code do its bidding). > > > >You mean code that could be put either into the kernel or live in userland > >- depending on the requirements of the underlying OS? > > > > > Or the requirements of the hardware, or the decisions of the driver > creator -- whichever. > > Of course, the kernel portion would potentially still have license > problems... it's not a total solution to that. But -- it does get as > much code as you want into userspace, without enforcing policies. > Right. > > > >Right, however there are people who like to have a more fine grained > >control over things than just accepting what the driver considers the > >best-match. > > > > > Right... what this says to me is that there have to be more possible > parameters in this string. > And some may even be driver dependent. Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Current discussion about the future of free software graphics
sottek writes: > Can we wrap this up the discussion and try to get to a consensus on > design requirements? I think most of the opinions are starting to > solidify enough to start hashing out the requirements and actual > design. > > Also, we probably want to drop the communication down to just one > list? I think dri-devel seems to have the widest group of subscribers. Well, I would think there are a lot more people who are interested in this subject than are subscribed on dri-devel. dri-devel really has a different scope. > 4: Design must insure that user applications may not set the hardware > into an unstable state that could lead to lockup or damage display > devices. The 'driver' must do mode validation using data supplied by either the display itself or the application (you need the second as some display devices may not support sending this data or the data sent is bogus). Broken video modes usually result from: 1. broken drivers 2. bogus user level configuration/override Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Current discussion about the future of free software graphics
On Tue, 2004-05-11 at 20:09, sottek wrote: > Can we wrap this up the discussion and try to get to a consensus on > design requirements? I think most of the opinions are starting to > solidify enough to start hashing out the requirements and actual > design. I agree, and I like your initial list of requirements. > Also, we probably want to drop the communication down to just one > list? I think dri-devel seems to have the widest group of subscribers. I agree with Geert, that probably doesn't cut it. Maybe start a new list and widely send out invitations to discuss the design there? -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Memory management of AGP and VRAM
Sottek, Matthew J writes: > > >Boy, I haven't really been following this too closely, but surely this > >sort of thing can be resolved with an extension mechanism or api > >versioning? > > An extension mechanism is fine for eventually extending the basic > functionality, but a driver writer should not have to wait for consensus > to add required features to their driver. Currently I don't think we Right. Therefore I would call for an extendable API with driver private parts. There is a basic API to handle a minimal set required to make a dump fb work. Something that can be supported by almost any chip there is. Then augment this with an 'optinal' part which handles stuff that is beyond the basics but well understood and supported by more than one driver. Above this put a driver private API. Stuff in there may over time be merged into the optional part when things are well understood and we can find a common denominator. > could get very much consensus on anything other than a very basic API > so saying that advanced features can be defined extensions is perhaps > too optimistic. If the advanced features can just remain device > dependent > extensions, at least in the beginning, then we can probably make some > actual progress in getting to a design. > > API versioning is a must no matter what. Right. Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: From Eric Anholt:
On Tue, May 11, 2004 at 04:43:29PM -0700, Greg KH wrote: > On Tue, May 11, 2004 at 07:34:39PM -0400, [EMAIL PROTECTED] wrote: > > On Wed, 12 May 2004 00:20:51 BST, Dave Airlie said: > > > > > I just looked at drm.h and nearly all the ioctls use int, this file is > > > included in user-space applications also at the moment, I'm worried > > > changing all ints to __u32 will break some of these, anyone on DRI list > > > care to comment? > > > > Is this a case where somebody is *really* including kernel headers in userspace > > and we need to smack them, or are they using a copy that's been sanitized > > (and possibly fixed)? > > Don't know, but how are you dealing with the issue that an "int" is > different for different kernel sizes (64 vs 32) and userspace too. > That's why you can't use it in an ioctl and expect things to work > properly. I'm not disagreeing that it ought to use __u32, but are there any Linux supported targets that don't have a 32-bit int? It's long that tends to change size. -- Daniel Jacobowitz --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: From Eric Anholt:
On Wed, 12 May 2004 00:20:51 BST, Dave Airlie said: > I just looked at drm.h and nearly all the ioctls use int, this file is > included in user-space applications also at the moment, I'm worried > changing all ints to __u32 will break some of these, anyone on DRI list > care to comment? Is this a case where somebody is *really* including kernel headers in userspace and we need to smack them, or are they using a copy that's been sanitized (and possibly fixed)? pgp0.pgp Description: PGP signature
Re: From Eric Anholt:
On Tue, May 11, 2004 at 06:07:27PM -0700, Jon Smirl wrote: > Would int16_t and int32_t work? No, sorry. See the lkml archives for why. > Those int's were in there before I started working on it. __u16 and > __u32 are Linux kernel defines that aren't always there in user space. Don't share header files between userspace and the kernel. End of problem :) thanks, greg k-h --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: From Eric Anholt:
On Tue, May 11, 2004 at 07:34:39PM -0400, [EMAIL PROTECTED] wrote: > On Wed, 12 May 2004 00:20:51 BST, Dave Airlie said: > > > I just looked at drm.h and nearly all the ioctls use int, this file is > > included in user-space applications also at the moment, I'm worried > > changing all ints to __u32 will break some of these, anyone on DRI list > > care to comment? > > Is this a case where somebody is *really* including kernel headers in userspace > and we need to smack them, or are they using a copy that's been sanitized > (and possibly fixed)? Don't know, but how are you dealing with the issue that an "int" is different for different kernel sizes (64 vs 32) and userspace too. That's why you can't use it in an ioctl and expect things to work properly. thanks, greg k-h --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: From Eric Anholt:
On Tue, May 11, 2004 at 08:07:09PM -0400, Daniel Jacobowitz wrote: > On Tue, May 11, 2004 at 04:43:29PM -0700, Greg KH wrote: > > On Tue, May 11, 2004 at 07:34:39PM -0400, [EMAIL PROTECTED] wrote: > > > On Wed, 12 May 2004 00:20:51 BST, Dave Airlie said: > > > > > > > I just looked at drm.h and nearly all the ioctls use int, this file is > > > > included in user-space applications also at the moment, I'm worried > > > > changing all ints to __u32 will break some of these, anyone on DRI list > > > > care to comment? > > > > > > Is this a case where somebody is *really* including kernel headers in userspace > > > and we need to smack them, or are they using a copy that's been sanitized > > > (and possibly fixed)? > > > > Don't know, but how are you dealing with the issue that an "int" is > > different for different kernel sizes (64 vs 32) and userspace too. > > That's why you can't use it in an ioctl and expect things to work > > properly. > > I'm not disagreeing that it ought to use __u32, but are there any Linux > supported targets that don't have a 32-bit int? It's long that tends > to change size. I don't think so, but I am not sure. That's why you should use __u32 to keep people from guessing :) thanks, greg k-h --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
Ian Romanick wrote:
James Simmons wrote:
1: Design must provide a mechanism for basic mode setting in a
device independent manner from an application with user level
permissions. ("Basic" to be defined)
Ug. I see I'm fighting a losing battle but it doesn't matter. I
couldn't never win this fight. There is MONEY involved here. This is a
sure way
to make sure Tungstengraphics has a income coming in. They want a
monoply on the linux graphics arena then fine they can have it.
Are you completely without a clue? Nobody from TG is even participating
in this discussion (except a couple messages from Jens a week or so
ago). Why would you even say such a thing?
I do feel remiss that I'm not engaged more fully in this, but really much of
the ground covered is way outside the areas in which I feel qualified to
comment, or perhaps it's just that I don't have an opinion either way about
mode-setting, etc, based on long years of just having the X server take care
of it for me...
Anyway. I've got a lot of respect for the people involved in the discussion,
even when they hold quite conflicting views, so I'm hopeful that some sort of
direction can be reached for moving forward.
My one worry about the discussion is that because of confusion over where the
X developers are hanging out nowadays, they are missing out on having their
say on this - and they probably care deeply about modesetting. Though, given
the mad flamewar it's turned into, maybe smaller is better...
Keith
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
