Menu
▾
▴
linux-fbdev-devel
|
From: Michel <mic...@ii...> - 2001-06-22 00:17:06
Attachments:
aty128fb-16bit.diff
|
The attached patch significantly enhances the 16 bit handling of aty128fb. I've achieved this mainly by consequently distinguishing between 'depth' and 'bpp'. I've used these terms for the same meanings as in XFree86 4.x; please let me know if you prefer other terms. While this now works perfectly in X for both depth 15 and 16 as well as in console for fbset -depth 16 -rgba 5,5,5,0 , some colors are wrong for fbset -depth 16 -rgba 5,6,5,0 . It's not clear to me whether the palette for 565 should have 32 or 64 entries. The patch is against 2.4.5-pre3 from Benjamin Herrenschmidt's tree so the offsets are probably off for Linus' tree. BTW I'd love to work on adding Rage128 and Radeon support to the new atyfb. PS: Ah yes, the patch also fixes panning. :) -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: Geert U. <ge...@li...> - 2001-06-22 08:03:54
|
On Fri, 22 Jun 2001, Michel D=E4nzer wrote:
> While this now works perfectly in X for both depth 15 and 16 as well as=
in
> console for fbset -depth 16 -rgba 5,5,5,0 , some colors are wrong for
> fbset -depth 16 -rgba 5,6,5,0 . It's not clear to me whether the palett=
e for
Funny, I have similar problems with atyfb and 565 (didn't manage to get X
working yet, since I still use 3.3.6 which seems to pass invalid paramete=
rs
when being `strict' in the color bitfield checking).
> 565 should have 32 or 64 entries.
64 of course. But red and blue should fill the first 32 entries only.
> BTW I'd love to work on adding Rage128 and Radeon support to the new at=
yfb.
Please coordinate with Ani, he already started to work on that.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org
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
|
|
From: Michel <mic...@ii...> - 2001-06-22 11:00:26
|
Geert Uytterhoeven wrote:
>
> On Fri, 22 Jun 2001, Michel Dänzer wrote:
> > While this now works perfectly in X for both depth 15 and 16 as well as in
> > console for fbset -depth 16 -rgba 5,5,5,0 , some colors are wrong for
> > fbset -depth 16 -rgba 5,6,5,0 . It's not clear to me whether the palette
> > for
>
> Funny, I have similar problems with atyfb and 565 (didn't manage to get X
> working yet, since I still use 3.3.6 which seems to pass invalid parameters
> when being `strict' in the color bitfield checking).
I know, Michael Schmitz forwarded your patch to me, it helped me a lot,
thanks.
> > 565 should have 32 or 64 entries.
>
> 64 of course. But red and blue should fill the first 32 entries only.
Okay, but why do you allocate a cmap with only 32 entries then? Do you
extrapolate the missing green entries in this line?
green = info->palette[(2*regno) & 0xff].green;
^^^^^^^^^^^^^^^^
I don't understand what this is supposed to do. As 0<regno<32, (2*regno) can't
be greater than 255, so what's the 0xff for?
> > BTW I'd love to work on adding Rage128 and Radeon support to the new
> > atyfb.
>
> Please coordinate with Ani, he already started to work on that.
Seems he and I are doing the same things a lot recently. :)
--
Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast \ XFree86 and DRI project member
|
|
From: Geert U. <ge...@li...> - 2001-06-22 11:14:40
|
On Fri, 22 Jun 2001, Michel D=E4nzer wrote:
> Geert Uytterhoeven wrote:
> > On Fri, 22 Jun 2001, Michel D=E4nzer wrote:
> > > While this now works perfectly in X for both depth 15 and 16 as wel=
l as in
> > > console for fbset -depth 16 -rgba 5,5,5,0 , some colors are wrong f=
or
> > > fbset -depth 16 -rgba 5,6,5,0 . It's not clear to me whether the pa=
lette
> > > for
> >=20
> > Funny, I have similar problems with atyfb and 565 (didn't manage to g=
et X
> > working yet, since I still use 3.3.6 which seems to pass invalid para=
meters
> > when being `strict' in the color bitfield checking).
>=20
> I know, Michael Schmitz forwarded your patch to me, it helped me a lot,
> thanks.
>=20
> > > 565 should have 32 or 64 entries.
> >=20
> > 64 of course. But red and blue should fill the first 32 entries only.
>=20
> Okay, but why do you allocate a cmap with only 32 entries then? Do you
> extrapolate the missing green entries in this line?
>=20
> green =3D info->palette[(2*regno) & 0xff].green;
> ^^^^^^^^^^^^^^^^
> I don't understand what this is supposed to do. As 0<regno<32, (2*regno=
) can't
For palette index regno, red and blue are stored in a different DAC entry=
than
green. So when I store red and blue, I have to make sure I write the corr=
ect
green value there. That green value is palette[regno*2].green. Follow the
fall-through and merge the code:
aty_st_dac(regno << 2, palette[regno/2].red, green, palette[regno/2].=
blue);
aty_st_dac(regno << 3, red, palette[(2*regno) & 0xff].green, blue);
> be greater than 255, so what's the 0xff for?
I wanted to be sure, you never know...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org
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
|
|
From: Michel <mic...@ii...> - 2001-06-22 11:38:00
|
Geert Uytterhoeven wrote: > > On Fri, 22 Jun 2001, Michel Dänzer wrote: > > Geert Uytterhoeven wrote: > > > On Fri, 22 Jun 2001, Michel Dänzer wrote: > > > > While this now works perfectly in X for both depth 15 and 16 as well as in > > > > console for fbset -depth 16 -rgba 5,5,5,0 , some colors are wrong for > > > > fbset -depth 16 -rgba 5,6,5,0 . It's not clear to me whether the palette > > > > for > > > > > > Funny, I have similar problems with atyfb and 565 (didn't manage to get X > > > working yet, since I still use 3.3.6 which seems to pass invalid parameters > > > when being `strict' in the color bitfield checking). > > > > I know, Michael Schmitz forwarded your patch to me, it helped me a lot, > > thanks. > > > > > > 565 should have 32 or 64 entries. > > > > > > 64 of course. But red and blue should fill the first 32 entries only. > > > > Okay, but why do you allocate a cmap with only 32 entries then? Do you > > extrapolate the missing green entries in this line? > > > > green = info->palette[(2*regno) & 0xff].green; > > ^^^^^^^^^^^^^^^^ > > I don't understand what this is supposed to do. As 0<regno<32, (2*regno) > > can't > > For palette index regno, red and blue are stored in a different DAC entry > than green. So when I store red and blue, I have to make sure I write the > correct green value there. That green value is palette[regno*2].green. > Follow the fall-through and merge the code: > > aty_st_dac(regno << 2, palette[regno/2].red, green, > palette[regno/2].blue); > aty_st_dac(regno << 3, red, palette[(2*regno) & 0xff].green, blue); Okay, I think I understand now. XFree86 actually sends 64 entries so that has to be dealt with. I'm going to use the 1 1/4 hours on the train for some more hacking... -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: James S. <jsi...@tr...> - 2001-06-22 16:41:51
|
> > BTW I'd love to work on adding Rage128 and Radeon support to the new atyfb. > > Please coordinate with Ani, he already started to work on that. Is this such a wise idea? I know the ati 128 can be run in DMA mode but can a MACH 64 card also be done in DMA? Once 2.5.X comes out and the patches I have go in we can migrate to using DMA/irq. The rage 128 works far far better in CCE mode plus the accel engine is far more stable. You can tell the ATI engineers focus on DMA performance and stability over mmio. |
|
From: Geert U. <ge...@li...> - 2001-06-22 17:01:36
|
On Fri, 22 Jun 2001, James Simmons wrote:
> > > BTW I'd love to work on adding Rage128 and Radeon support to the new atyfb.
> >
> > Please coordinate with Ani, he already started to work on that.
>
> Is this such a wise idea? I know the ati 128 can be run in DMA mode but
> can a MACH 64 card also be done in DMA? Once 2.5.X comes out and the
> patches I have go in we can migrate to using DMA/irq. The rage 128 works
> far far better in CCE mode plus the accel engine is far more stable. You
> can tell the ATI engineers focus on DMA performance and stability over
> mmio.
At least the 3D RAGE II+ and 3D RAGE PRO have support for busmastering DMA,
including queueing acceleration commands in a buffer in RAM.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: Michel <mic...@ii...> - 2001-06-24 18:06:14
|
James Simmons wrote: > > > > BTW I'd love to work on adding Rage128 and Radeon support to the new > > > atyfb. > > > > Please coordinate with Ani, he already started to work on that. > > Is this such a wise idea? I know the ati 128 can be run in DMA mode but > can a MACH 64 card also be done in DMA? Once 2.5.X comes out and the > patches I have go in we can migrate to using DMA/irq. I hope this is going to use the existing DRM infrastructure? Anyway, switching from MMIO to CCE accel shouldn't be a big deal, and it can't hurt to have the basic support in place when doing it, can it? -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: James S. <jsi...@tr...> - 2001-06-24 20:14:30
|
> I hope this is going to use the existing DRM infrastructure? No!!!!!!!! For 2.5.X the console will switch between "graphics" mode to "text" mode. When swithcing from one to the other it will place the engine in a different state. > Anyway, switching from MMIO to CCE accel shouldn't be a big deal, and it can't > hurt to have the basic support in place when doing it, can it? Well the driver will be completely different. CCE is very different from MMIO mode for the Rage 128. I found switching between the two to be very tricky. |
|
From: Michel <mic...@ii...> - 2001-06-24 20:18:11
|
James Simmons wrote: > > > I hope this is going to use the existing DRM infrastructure? > > No!!!!!!!! For 2.5.X the console will switch between "graphics" mode to > "text" mode. When swithcing from one to the other it will place the engine > in a different state. Fine, but what's the _reason_ not to use the DRM? :) > > Anyway, switching from MMIO to CCE accel shouldn't be a big deal, and it > > can't hurt to have the basic support in place when doing it, can it? > > Well the driver will be completely different. CCE is very different from > MMIO mode for the Rage 128. I found switching between the two to be very > tricky. In the XFree86 r128 driver, it looks rather easy... Besides, by 'switching' I meant replacing the MMIO accel functions by DMA ones. -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: James S. <jsi...@tr...> - 2001-06-24 20:27:44
|
> > No!!!!!!!! For 2.5.X the console will switch between "graphics" mode to > > "text" mode. When swithcing from one to the other it will place the engine > > in a different state. > > Fine, but what's the _reason_ not to use the DRM? :) DRM is overkill for what we need. It would only end up bloating the system. We just need to setup the DMA engine and send in 3 basic 2D accels. > In the XFree86 r128 driver, it looks rather easy... Besides, by 'switching' I > meant replacing the MMIO accel functions by DMA ones. Okay. That is fine. |
|
From: Sven L. <lu...@dp...> - 2001-06-24 21:18:55
|
On Sun, Jun 24, 2001 at 01:27:38PM -0700, James Simmons wrote: > > > > No!!!!!!!! For 2.5.X the console will switch between "graphics" mode to > > > "text" mode. When swithcing from one to the other it will place the engine > > > in a different state. > > > > Fine, but what's the _reason_ not to use the DRM? :) > > DRM is overkill for what we need. It would only end up bloating the > system. We just need to setup the DMA engine and send in 3 basic 2D > accels. mmm, ... I am thinking of a user-space library to do video acceleration on the framebuffer, for initial use with vlc, as it already has an fbdev output option. If i want to do dma with this library, should i need to use the drm, or is some other possibilities available ? How will a user-space library using the accel engine (it would clearly need a little 'driver' for each chip) cohabit with the acceleration used with fbcon ? Also i suppose by "graphic" mode you are speaking about X, and by "text" mode, you are speaking about fbcon ? Who will be responsible for setting the accel engine in a different state ? as XFree clearly thinks it is his responsability to do such. Or are you thinking only about the new X server ? Friendly, Sven Luther |
|
From: James S. <jsi...@tr...> - 2001-06-27 16:41:40
|
> If i want to do dma with this library, should i need to use the drm, or is > some other possibilities available ? For now yes. First the fbdev cleanup then the merging of DRI and fbdev. The merging has to be done very carefully since hardware various quite dramatically when going from PDAs to high end rendering farms. > How will a user-space library using the accel engine (it would clearly need a > little 'driver' for each chip) cohabit with the acceleration used with fbcon ? > > Also i suppose by "graphic" mode you are speaking about X, and by "text" mode, > you are speaking about fbcon ? Yes. fbcon would shutdown when going into "graphics" mode. This would prevent any conflicts. > Who will be responsible for setting the accel engine in a different state ? as > XFree clearly thinks it is his responsability to do such. Or are you thinking > only about the new X server ? XFree86 is wrong in this department. The console system should handle it. Who better to the knwo the hardware of the console system than the console system itself. As linux is ported to more and more platforms less and less of that graphics hardware will support vga text mode. Even when you place your video card in a vga text mode besides 80x25 XFree86 has a hard time. It makes to many assumptions which end up being wrong. Even without my console changes XFree86 is broken. With my changes it still will be broken. It just in the case of the new console code it reset the mode itself and in the process fix any stupid mistakes XFree86 made. |
|
From: Scott A M. <sam...@co...> - 2001-06-27 17:15:10
|
I have the impression that some of the card vendors are thinking about or have started to use DMA in some of their Xservers. There is not a common API for access to the DMA... Will the fbcon and the Xserver be stepping on each others use of DMA? Or am I looking for an issue that does not exist? What is driving the need to accelerate the console? -- Scott A. McConnell |
|
From: Sven L. <lu...@dp...> - 2001-06-27 21:02:48
|
On Wed, Jun 27, 2001 at 09:41:34AM -0700, James Simmons wrote: > > > If i want to do dma with this library, should i need to use the drm, or is > > some other possibilities available ? > > For now yes. First the fbdev cleanup then the merging of DRI and fbdev. > The merging has to be done very carefully since hardware various quite > dramatically when going from PDAs to high end rendering farms. You are speaking about the merging as something that will happen inevitably, and quite soon also. How is it really, do the DRI people know you intent to merge the drm and fbdev ? What do they think about it ? I suppose it is quite political stuff, isn't it ? > > How will a user-space library using the accel engine (it would clearly need a > > little 'driver' for each chip) cohabit with the acceleration used with fbcon ? > > > > Also i suppose by "graphic" mode you are speaking about X, and by "text" mode, > > you are speaking about fbcon ? > > Yes. fbcon would shutdown when going into "graphics" mode. This would > prevent any conflicts. What about if an app wants to take over let's say the top 4/3 orsomething such of the screen (in order to open a 16/9 or whatever video playback window or something such) and keep fbcon active in the lower part, in order for the app to do it's I/O ? > > Who will be responsible for setting the accel engine in a different state ? as > > XFree clearly thinks it is his responsability to do such. Or are you thinking > > only about the new X server ? > > XFree86 is wrong in this department. The console system should handle it. Ah, sure, but Xfree86 is the main app out there, and it is they who really own the linux desktop. And they also have the most visibility right now. > Who better to the knwo the hardware of the console system than the console > system itself. As linux is ported to more and more platforms less and less > of that graphics hardware will support vga text mode. Even when you place > your video card in a vga text mode besides 80x25 XFree86 has a hard time. > It makes to many assumptions which end up being wrong. Even without my > console changes XFree86 is broken. With my changes it still will be > broken. It just in the case of the new console code it reset the mode > itself and in the process fix any stupid mistakes XFree86 made. yes, fbdev support in linux needs some work, but it can be fixed, if someone is willing to do the job. But again, X actually thinks that they are responsible for handling the card, and the DRI follows their lead. It is the X driver who handles the switch between the 2D and various 3D contexts. How will using hardware access on the console handle this ? Ok, i guesss using standard register writing should work without problem, but what about the dma stuff ? if you use the drm you interact with X. That said, all this is not really all that clear in my mind right now. Friendly, Sven Luther > |
|
From: Michel <mic...@ii...> - 2001-06-27 21:18:47
|
Sven LUTHER wrote: > > Who better to the knwo the hardware of the console system than the console > > system itself. As linux is ported to more and more platforms less and less > > of that graphics hardware will support vga text mode. Even when you place > > your video card in a vga text mode besides 80x25 XFree86 has a hard time. > > It makes to many assumptions which end up being wrong. Even without my > > console changes XFree86 is broken. With my changes it still will be > > broken. It just in the case of the new console code it reset the mode > > itself and in the process fix any stupid mistakes XFree86 made. > > yes, fbdev support in linux needs some work, but it can be fixed, if someone > is willing to do the job. I seem to be the only one willing to do it. The plan has been evolving in my head for some time, but I don't feel quite ready to attack it yet. If all else fails, I'll have to lock myself with just my PowerBook and enough food to survive into a room for a few days. :) > But again, X actually thinks that they are responsible for handling the > card, and the DRI follows their lead. It is the X driver who handles the > switch between the 2D and various 3D contexts. That's not correct. In the DRI context, the X server is one of many clients the DRM mediates hardware access between. > How will using hardware access on the console handle this ? I imagine fbcon would have to be a client of the DRM as well. -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: Sven L. <lu...@dp...> - 2001-06-27 21:28:13
|
On Wed, Jun 27, 2001 at 11:18:07PM +0200, Michel D=E4nzer wrote: > Sven LUTHER wrote: > > But again, X actually thinks that they are responsible for handling t= he > > card, and the DRI follows their lead. It is the X driver who handles = the > > switch between the 2D and various 3D contexts. >=20 > That's not correct. In the DRI context, the X server is one of many cli= ents > the DRM mediates hardware access between. mmm, but itis the X driver which fournish the register save/restore routi= ns, at least that is how i see it. True it is the drm who calls them, i think= , but still, if you have no X running, i don't know how the save/restore stuff = is handled. I suppose you could have any user app initializing the drm with the conte= c=3Dxt swithc function, but X and drm are very thigly intertwined. Also, it seems the drm modules (or builtins) know really nothing about th= e underlaying hardware, it is the X server who tells them where the chip is= , and what kind of chip to use. > > How will using hardware access on the console handle this ? >=20 > I imagine fbcon would have to be a client of the DRM as well. Sure, but will it not conflict with X ? DRI was built with 1 2D client an= d multiple 3d client in mind. I don't think it will run with more than 1 D2 client right now. That said, my knowledge is rather fragmentary, it comes from studying the glint driver (hardly the most advanced DRI support, altough it was the fi= rst DRI implementation back then)in hope to find time to implement DRI suppor= t for giamma + permedia3 or permedia3 alone. Friendly, Sven Luther |
|
From: Michel <mic...@ii...> - 2001-06-27 21:45:15
|
Sven LUTHER wrote: > > On Wed, Jun 27, 2001 at 11:18:07PM +0200, Michel Dänzer wrote: > > Sven LUTHER wrote: > > > But again, X actually thinks that they are responsible for handling the > > > card, and the DRI follows their lead. It is the X driver who handles the > > > switch between the 2D and various 3D contexts. > > > > That's not correct. In the DRI context, the X server is one of many > > clients the DRM mediates hardware access between. > > mmm, but itis the X driver which fournish the register save/restore routins, > at least that is how i see it. True it is the drm who calls them, i think, > but still, if you have no X running, i don't know how the save/restore stuff > is handled. This is also getting shaky ground for me, but AFAIK each client of the DRM is responsible to maintain its own context. > I suppose you could have any user app initializing the drm with the > contec=xt swithc function, but X and drm are very thigly intertwined. There must be special communication between the X server and its clients because they need to know where the windows are etc. > Also, it seems the drm modules (or builtins) know really nothing about the > underlaying hardware, it is the X server who tells them where the chip is, > and what kind of chip to use. Nope, the DRM finds the chip on its own. Just load the module and watch its output. > > > How will using hardware access on the console handle this ? > > > > I imagine fbcon would have to be a client of the DRM as well. > > Sure, but will it not conflict with X ? DRI was built with 1 2D client and > multiple 3d client in mind. I don't think it will run with more than 1 D2 > client right now. Sure, the status quo is that when switching away from the X VT, the X server grabs the hardware lock, thus preventing any other client from banging the hardware. That would have to be changed, which makes this ever happening quite a bit less probable, given that the console system on other OSs can't do the same. At any rate, this will have to be discussed with the major DRI hackers. The address is dri...@li... . :) -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: Sven L. <lu...@dp...> - 2001-06-27 22:22:05
|
On Wed, Jun 27, 2001 at 11:44:55PM +0200, Michel D=E4nzer wrote: > Sven LUTHER wrote: > >=20 > > On Wed, Jun 27, 2001 at 11:18:07PM +0200, Michel D=E4nzer wrote: > > > Sven LUTHER wrote: > > > > But again, X actually thinks that they are responsible for handli= ng the > > > > card, and the DRI follows their lead. It is the X driver who hand= les the > > > > switch between the 2D and various 3D contexts. > > > > > > That's not correct. In the DRI context, the X server is one of many > > > clients the DRM mediates hardware access between. > >=20 > > mmm, but itis the X driver which fournish the register save/restore r= outins, > > at least that is how i see it. True it is the drm who calls them, i t= hink, > > but still, if you have no X running, i don't know how the save/restor= e stuff > > is handled. >=20 > This is also getting shaky ground for me, but AFAIK each client of the = DRM is > responsible to maintain its own context. At least in the glint driver, in the glint_dri.c function, there is a fun= ction called glint_switch_context or something such, which can save and restore= both 2D and 3D contextes. I have not seen any such thing in the openGL/mesa code, but then i did no= t look yet much at it. From what i see, the X glint driver fills in the function in the dRI structure, and later on, dri/drm can call it when switching context. > > I suppose you could have any user app initializing the drm with the > > contec=3Dxt swithc function, but X and drm are very thigly intertwine= d. >=20 > There must be special communication between the X server and its client= s > because they need to know where the windows are etc. Yes, but it is much more than that, i have the feeling. > > Also, it seems the drm modules (or builtins) know really nothing abou= t the > > underlaying hardware, it is the X server who tells them where the chi= p is, > > and what kind of chip to use. >=20 > Nope, the DRM finds the chip on its own. Just load the module and watch= its > output. No, i was able to load the gamma module on a matrox G400 equiped system. = Am sure if i provided it with the right values, it would have happily tried = to write to the G400 as it was a gamma chip. Have'nt tried though, and could= have missed some identification stuff. Anyway, the kernel part of the drm is rather dumb. Not much more than dma handling and interrupt stuff, or so it seems to me. Friendly, Sven Luther |
|
From: James S. <jsi...@tr...> - 2001-06-29 19:06:11
|
> You are speaking about the merging as something that will happen inevitably, > and quite soon also. No. It will be awhile. > How is it really, do the DRI people know you intent to > merge the drm and fbdev ? What do they think about it ? I suppose it is quite > political stuff, isn't it ? I have spoken to them before about this. They know it has to be done but don't really care abouot fixing the problem. > What about if an app wants to take over let's say the top 4/3 orsomething such > of the screen (in order to open a 16/9 or whatever video playback window or > something such) and keep fbcon active in the lower part, in order for the app > to do it's I/O ? In graphics mode it should draw the fonts itself. Does X use the console to draw its fonts? No, of course not. Userland drawing fonts has a few advantages as well. One with mmap mmio regions you avoid going threw many layers of the console to draw fonts. Second you have much more control over the fonts including writing asian fonts which can't be done very well in the current console system. > > XFree86 is wrong in this department. The console system should handle it. > > Ah, sure, but Xfree86 is the main app out there, and it is they who really own > the linux desktop. And they also have the most visibility right now. So M$ windows owns the PC market. Does this make the way they do software the right way? In time XFrre86 WILL discover this as linux works across more and more types of hardware. > But again, X actually thinks that they are responsible for handling the card, > and the DRI follows their lead. It is the X driver who handles the switch > between the 2D and various 3D contexts. How will using hardware access on the > console handle this ? Console will be shutdown in "graphics" mode. This is the way IRIX has handled it for more than 10 some odd years. It has been proven to work. |
|
From: Sven L. <lu...@dp...> - 2001-06-30 06:29:33
|
On Fri, Jun 29, 2001 at 12:05:56PM -0700, James Simmons wrote: > > > You are speaking about the merging as something that will happen inevitably, > > and quite soon also. > > No. It will be awhile. > > > How is it really, do the DRI people know you intent to > > merge the drm and fbdev ? What do they think about it ? I suppose it is quite > > political stuff, isn't it ? > > I have spoken to them before about this. They know it has to be done but > don't really care abouot fixing the problem. > > > What about if an app wants to take over let's say the top 4/3 orsomething such > > of the screen (in order to open a 16/9 or whatever video playback window or > > something such) and keep fbcon active in the lower part, in order for the app > > to do it's I/O ? > > In graphics mode it should draw the fonts itself. Does X use the console > to draw its fonts? No, of course not. Userland drawing fonts has a few > advantages as well. One with mmap mmio regions you avoid going threw many > layers of the console to draw fonts. Second you have much more control > over the fonts including writing asian fonts which can't be done very well > in the current console system. but will you have access to the font drawing accels of fbdev, or should you do it by hand ? Friendly, Sven Luther |
|
From: James S. <jsi...@tr...> - 2001-07-01 14:28:13
|
> but will you have access to the font drawing accels of fbdev, or should you do > it by hand ? No. It is to slow that way. It is better if userland does it itself. Plus you have code to use inside the kernel. |
|
From: Sven L. <lu...@dp...> - 2001-07-02 06:52:41
|
On Sun, Jul 01, 2001 at 07:27:39AM -0700, James Simmons wrote: > > > but will you have access to the font drawing accels of fbdev, or should you do > > it by hand ? > > No. It is to slow that way. It is better if userland does it itself. Plus > you have code to use inside the kernel. But that would mean a 3rd serie of drivers, in a userland library that would enable some kind of accel ofor userland fbdev apps. Having 2 copies of the drivers 'fbdev + X) is bad enough, without needing to maintain a 3rd version. That is, unless we manage to re-use the X drivers in some way, or go with full mesa/openGL ... Friendly, Sven Luther |
|
From: Michel <mic...@ii...> - 2001-06-27 21:08:49
|
James Simmons wrote: > > > If i want to do dma with this library, should i need to use the drm, or is > > some other possibilities available ? > > For now yes. First the fbdev cleanup then the merging of DRI and fbdev. Now that you had me convinced that using the DRM isn't sensible... > The merging has to be done very carefully since hardware various quite > dramatically when going from PDAs to high end rendering farms. I'm curious how things will work out. > > Who will be responsible for setting the accel engine in a different state > > ? as XFree clearly thinks it is his responsability to do such. Or are you > > thinking only about the new X server ? > > XFree86 is wrong in this department. Hmm, XFree86 says you are wrong. ;) > The console system should handle it. Who better to the knwo the hardware of > the console system than the console system itself. As linux is ported to > more and more platforms less and less of that graphics hardware will support > vga text mode. Even when you place your video card in a vga text mode > besides 80x25 XFree86 has a hard time. It makes to many assumptions which > end up being wrong. Even without my console changes XFree86 is broken. With > my changes it still will be broken. While I mostly agree for fbcon on Linux, I think this is a strong statement. XFree86 tries hard to save and restore video of the VT it runs on. Granted, it doesn't always work perfectly, but I'd say it works rather well given the assumptions it makes and that it doesn't need any OS support. > It just in the case of the new console code it reset the mode > itself and in the process fix any stupid mistakes XFree86 made. I'll also try to make XFree86 use the fbcon interface whenever appropriate. -- Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \ XFree86 and DRI project member |
|
From: James S. <jsi...@tr...> - 2001-06-29 19:10:03
|
> > XFree86 is wrong in this department. > > Hmm, XFree86 says you are wrong. ;) They will find out the hard way :-/ > While I mostly agree for fbcon on Linux, I think this is a strong statement. > XFree86 tries hard to save and restore video of the VT it runs on. Which is also bad. In the future (2.5.X) with the seperation of fbdev from the console system it will be possible to run /dev/fb without a console. A console makes no sense on a PDA which lacks a keyboard. I found out the hardware XFree86 doesn't like this. Well given the year or more devleopement cycle of XFree86 they will fix about 2003. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X