Menu
▾
▴
linux-fbdev-devel — linux-fbdev mailing list for project developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Geert U. <ge...@li...> - 2001-05-09 15:48:06
|
On Wed, 9 May 2001, Scott A McConnell wrote:
> I was wondering how the four new accelerated functions were to be used
> by user land apps.
>
> (via ioctls? Wouldn't that be slow?)
They are not intended to be used by user land apps, only by the kernel console
driver.
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: Scott A M. <sam...@co...> - 2001-05-09 15:26:49
|
I was wondering how the four new accelerated functions were to be used by user land apps. (via ioctls? Wouldn't that be slow?) Will XFBDev support the new calls? What about other graphics programs are they planning on using them. -- Scott A. McConnell |
|
From: Geert U. <ge...@li...> - 2001-05-04 08:47:09
|
On Thu, 3 May 2001, Geert Uytterhoeven wrote: > Finally I found some time to incorporate the very nice logos contributed by > Simon Budig. Thank you Simon! > > Patches (for both 2.4.5-pre1 and 2.4.4-ac4) can be downloaded from: > > http://home.tvd.be/cr26864/Linux/fbdev/logo.html Sorry, I had forgotten to upload the new logo for SPARC. Fixed. 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: Geert U. <ge...@li...> - 2001-05-03 20:19:48
|
Finally I found some time to incorporate the very nice logos contributed by
Simon Budig. Thank you Simon!
Patches (for both 2.4.5-pre1 and 2.4.4-ac4) can be downloaded from:
http://home.tvd.be/cr26864/Linux/fbdev/logo.html
This page also shows the curent, old and new logos, and includes a tool to
extract logos in PNM format from the kernel sources (in case you don't trust me
:-) and a (NEW!) tool to convert logos in PNM format to C source suitable for
inclusion in the kernel.
I hope these are OK for all of you, so we can finally have politically correct
and good looking boot logos!
Changelog:
- 2001/05/03:
o Use the logos from Simon Budig.
o Add pnmtologo.
o Rename ARCH_LINUX_LOGO to __HAVE_ARCH_LINUX_LOGO*.
- 2001/03/08:
o This patch fixes some issues with the frame buffer device penguin logo
code.
o Bug list:
- The colors for the 16 color logo are wrong. We used a hack to give
the logo its own color palette, but this no longer works as a side
effect of a console color map bug being fixed a while ago. The
solution is to replace the logo with a new one that uses the
standard VGA console palette.
- There are still some politically-incorrect (PI) logos of a penguin
holding a glass of beer or wine (or perhaps even worse? :-).
o Changes:
1. Update the frame buffer console code to no longer change the
palette when displaying the 16 color logo. Remove the tricks to
load the logo palette in unused palette entries on displays with >=
32 colors.
2. Replace the PI 16 color Penguin-with-beer logo by a new one,
derived from the 224 color logo.
3. Remove a superfluous include from drivers/char/console.c. The logo
code was moved to drivers/video/fbcon.c a long time ago.
4. Replace the PI black & white Penguin-with-beer logo by a new one,
derived from the PostScript version on Larry Ewing's webpage.
5. Remove drivers/sgi/char/linux_logo.h (containing a PI 224 color
Penguin-with-beer logo) since it's no longer used.
6. Remove the PI black & white Penguin-with-wine logo used on SPARC
and SPARC64. Use the generic logo instead.
7. Move linux_logo_* prototypes to <linux/linux_logo.h>.
8. Simplify the logo selection logic in arch-specific
<asm-xxx/linux_logo.h>. If you want to have an arch-specific logo,
#define ARCH_LINUX_LOGO* and declare your data (if
INCLUDE_LINUX_LOGO_DATA is defined).
o Changes 1, 2 and 3 are already present in Alan's tree.
Change 5 is already present in the Linux/MIPS CVS tree.
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: <fl...@fl...> - 2001-04-28 10:28:32
|
Hello, I've got a certain question, concerning the aty128fb-driver status. In the README included to kernel 2.4.3 it says that the driver is still experimental, so it could be that the problem is already known, but I haven't found any patches to the last kernel updates - and I think it is quite stable - so I want to report the following: The only problem I have is using it together with a tvtuner-card. I can use it for normal TV-watching but if I use the fbtv-program and I change console during the program is running I get a freeze and I need to switch of the computer. The strange thing is, that I don't get this freeze always, but at least after the 2nd or 3rd console-switch. Others told me that same things happen if you use xawtv together with the DRI-structure. I'm afraid, I don't know programming, but if I can help someone solving the problem with debuging etc. I'd like to do that if you tell me how. My PC doesn't own any important files, so crashing is not a big problem for me. ;) The components are: ATI Rage 128 Xpert + Terratec TeraTvalue, all drivers taken from kernel 2.4.3, maybe 2.4.4 in the next days. Bye, Flo -- GPG-Key fingerprint = 7C9A 5D5A D392 4061 F7BF 743C E0A8 6490 591D 0EC2 Get-Key: mailto: pg...@fl... ICQ: #74585265 //and please excuse my english// |
|
From: Brad D. <br...@ne...> - 2001-04-27 21:10:08
|
Hello, I just want to take a minute to let those interested know that I'll be droping out of fbdev for medical reasons. I've pointed the DNS for the web site to sourceforge, so it can be further maintained from there, presumably by James Simmons. Ani Joshi will also be taking over maintainership for the Rage128 driver as well. Thanks, Brad Douglas br...@ne... |
|
From: <ti...@mc...> - 2001-04-26 18:13:58
|
> Jani wrote: > is there an effort to make trident framebuffer drivers? We are working on cyber9525DVD driver. We are looking for docs and we've alread asked to Alan Hourihane (X trident driver developper). In the mean time, we are trying to directly understand the X driver source. In any case once the documentation is available we hope to release the first pubblic version in one mounth. The Black Trident Project. -- Mattia (Tia) Crivellini Undergraduate Student of Computer Science, Bologna, Italy ------------------------------------------------------------------------------ Rappresentante degli studenti in Consiglio di Corso di Laurea e Dipartimento. ------------------------------------------------------------------------------ E-mail dept: cri...@cs... www.students.CS.UniBO.it/~crivelli |
|
From: Geert U. <ge...@li...> - 2001-04-26 15:36:31
|
---------- Forwarded message ---------- Date: Wed, 25 Apr 2001 19:47:14 +0300 (EEST) From: Jani Monoses <ja...@as...> To: lin...@vg... Subject: trident fb? Hi is there an effort to make trident framebuffer drivers? TIA, Jani. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to maj...@vg... More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |
|
From: Romain D. <do...@ir...> - 2001-04-25 09:32:36
|
Geert Uytterhoeven wrote: > Yep, we have to trust whoever has checkin rights. I don't think that will be a > big problem, though. If all driver devellopers have write access, it might cause trouble, simply because CVS is not foolproof. I know I almost blowed up my CVS tree once because of a typing mistake... those can happen to everyone, in particular when you finally sort out a bug at 3 AM :-) > According to the SourceForge docs, you have to ask a human at SourceForge to > import your existing repository. Yuck... Any point in trying to import pm3fb in SourceForge ? There isn't much interest in using it, it seems ; not a single report in two months of puclic availability, out of close to a hundred uniques domains accessing the web page :-( -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Geert U. <ge...@li...> - 2001-04-25 09:15:35
|
On Wed, 25 Apr 2001, Romain Dolbeau wrote:
> Geert Uytterhoeven wrote:
> > BTW, I'd like to see more drivers in CVS :-) I plan to check in the new atyfb
> > (the one in Alan's tree) soon.
>
> Mmmm, is there a way in CVS to give per-module write access ? If not,
> that means you have to trust everyone for everything, or to have
> every patch goes through a few people...
Yep, we have to trust whoever has checkin rights. I don't think that will be a
big problem, though.
> Also, can an import preserve existing CVS info like branch, revision
> number and the like ? (pm3fb is ATM on a private CVS, I'd like to be
> able to keep the history if it moves to linux-fbdev on SourceForge)
According to the SourceForge docs, you have to ask a human at SourceForge to
import your existing repository.
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: Romain D. <do...@ir...> - 2001-04-25 08:19:54
|
Geert Uytterhoeven wrote: > BTW, I'd like to see more drivers in CVS :-) I plan to check in the new atyfb > (the one in Alan's tree) soon. Mmmm, is there a way in CVS to give per-module write access ? If not, that means you have to trust everyone for everything, or to have every patch goes through a few people... Also, can an import preserve existing CVS info like branch, revision number and the like ? (pm3fb is ATM on a private CVS, I'd like to be able to keep the history if it moves to linux-fbdev on SourceForge) -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Jordan C. <jo...@Ce...> - 2001-04-24 14:16:24
|
Tea, thanks for passing this on! My driver is always available from http://cosmic.censoft.com. The most recent version is mostly a port of Adrian's driver to 2.4.X, and also provides dual head support for multiple C&T69K drivers. I know that Adrian was going to try to merge everything together to get a new Asiliant driver submitted to Linus and friends, but I don't know that is going (I know he is busy). There are 1 and 1/2 bugs that I have on my version - Somehow i did a stupid thing and made Tux disapear from the console during bootup. The other 1/2 bug is that the text scrolling is also confused during startup. Other than that, it works great. So grab it and see if it can help you. Jordan -- -- embed this! http://www.microwindows.org -- On Tuesday 24 April 2001 04:04, Tea Age mentioned: > On Monday 23 April 2001 18:59, Alex Pavloff <apa...@ea...> wrote: > > Hi Thomas... > > > > At my company, we're finishing up a board design for a single board > > computer that'll go into out industrial panels, and we're going to be > > running Linux on it (eventually). We've currently planning on using a > > Asiliant 69000 in our product, and with a pointer from Brad Douglas, > > found your page. We're going to be running Microwindows on our device, > > and since it's only a ZFLinux processor running at 128Mhz, we'd like as > > much power as possible. The 69000 was the only chip we could find that > > fit our needs (an x86 compatible embedded graphics chips that has > > integrated memory). > > > > Anyway, I was reading your comments at the end of ctfb.c, and noticed > > that you've got bitblt support and lots of other goodies on the wish > > list, and was wondering what your plans were on implementing them. > > > > Thanks! > > > > Alex Pavloff > > Software Engineer > > Eason Technology > > Hi Alex, > > currently I do no further work on ctfb and probably also not in the future. > The reason is simply hw related - we use other stuff now. > > That are the bad news. Now the good ones: > > 1) Mike McQuade <mi...@ci...> plans to add some hw acceleration. > > 2) Adrian Cox <ad...@hu...> wrote a similar driver (named > asiliantfb) and plans some futher work on it. > > 3) Jordan Crouse <jo...@Ce...> is also active in this field. He > modified the chipsfb to run with 69000. > > For mor details ask them or search the framebuffer mailing list archive > www.mail-archive.com/lin...@vu.... > > Thomas > > _______________________________________________ > Linux-fbdev-devel mailing list > Lin...@li... > http://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel |
|
From: Tea A. <lk...@vi...> - 2001-04-24 10:00:50
|
On Monday 23 April 2001 18:59, Alex Pavloff <apa...@ea...> wrote: > Hi Thomas... > > At my company, we're finishing up a board design for a single board > computer that'll go into out industrial panels, and we're going to be > running Linux on it (eventually). We've currently planning on using a > Asiliant 69000 in our product, and with a pointer from Brad Douglas, found > your page. We're going to be running Microwindows on our device, and since > it's only a ZFLinux processor running at 128Mhz, we'd like as much power as > possible. The 69000 was the only chip we could find that fit our needs (an > x86 compatible embedded graphics chips that has integrated memory). > > Anyway, I was reading your comments at the end of ctfb.c, and noticed that > you've got bitblt support and lots of other goodies on the wish list, and > was wondering what your plans were on implementing them. > > Thanks! > > Alex Pavloff > Software Engineer > Eason Technology Hi Alex, currently I do no further work on ctfb and probably also not in the future. The reason is simply hw related - we use other stuff now. That are the bad news. Now the good ones: 1) Mike McQuade <mi...@ci...> plans to add some hw acceleration. 2) Adrian Cox <ad...@hu...> wrote a similar driver (named asiliantfb) and plans some futher work on it. 3) Jordan Crouse <jo...@Ce...> is also active in this field. He modified the chipsfb to run with 69000. For mor details ask them or search the framebuffer mailing list archive www.mail-archive.com/lin...@vu.... Thomas |
|
From: Geert U. <ge...@li...> - 2001-04-24 09:39:53
|
I think it's worthwhile to feed CVS checkin logs to a mailing list.
Should I feed them to linux-fbdev-devel, or create a new list for them?
Contrary to the docs on SourceForge, it doesn't seem to be possible to create a
list with name *-cvs. The mailing list manager complains about a too short list
name.
BTW, I'd like to see more drivers in CVS :-) I plan to check in the new atyfb
(the one in Alan's tree) soon.
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: Geert U. <ge...@li...> - 2001-04-23 16:55:04
|
Hi,
I just checked in a preliminary version of fbtest.
The goal of fbtest is to have some simple tests that can be run to verify the
correctness of a frame buffer device. Performance is not the most important
property, correctness is.
The program is divided in three parts:
- drawops: frame buffer specific drawing operations, e.g. cfb8, planar, ...
- visops: visual operations. You can draw using different visuals
(monochrome, pseudocolor, truecolor, ...). Not all visuals are supported on
all hardware
- tests: so far I have 2 simple monochrome tests. They work fine on my
machine, using atyfb, in depths 8 (pseudocolor), 16, 24 and 32
(directcolor).
If I find more time, I'll tell you more about the internals.
Feel free to give it a try. You can check it out from
cvs.linux-fbdev.sourceforge.net, module name `fbtest'. Especially search for
`FIXME' and `not yet implemented' in the sources :-)
Enjoy!
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: BERECZ S. <sz...@in...> - 2001-04-21 22:50:58
|
Hi! in fb_write() if one wants to write more than smem_len begining with the 0th byte it's ok. but if one writes e.g. beginning with the 1st byte at least smem_len bytes, it gets ENOSPC. is it supposed to do that? so, for example I have a card with 16 bytes of mem :) : loff_t ppos=0; fb_write(foo, bar, 17, &ppos); it returns 16 loff_t ppos=1; fb_write(foo, bar, 16, &ppos); it returns ENOSPC I think it's at least confusing. (sorry if it's not correct. I don't have a card supported by fbdev) another "problem" in fb_read and fb_write I think you should use this if (count > fix.smem_len) instead of this if (count >= fix.smem_len) it does not make sense, but it's cleaner. (if there is no reason for using '>=') Bye, Szabi |
|
From: James S. <jsi...@li...> - 2001-04-19 16:39:42
|
>you are forking the XFree86, is that the wisest course ? Do you have >enough manpower and coding time as compared to the Xfree86 team ? Not forking. Starting from scratch. We don't plan to stick with the MIT sample implementation for long. New build system, the whole nine yards. For several months several dozen developers have been exchange emails planning this. >Could you please explain a bit more about the reasons of this, and >explain why it is a better course than working with the Xfree code, and >adapting it to our needs. We feel the catherdal method of developement of XFree86 is going to hurt linux in the long run. We need something to evolve as fast or faster than linux. Also XFree86 design goal is to work everywhere. You have to pay a price for this. We are not so ambitious. |
|
From: Romain D. <dol...@cl...> - 2001-04-19 09:52:37
|
James Simmons a *crit : > You have to specify which fb device to change. Otherwise it will always > change fb0. I did specify. But even so, fbset still display the wrong value. At boot time, all VT are on /dev/fb0. fbset on /dev/fb1 give proper result. I move vt2 on /dev/fb1. fbset in /dev/fb1 return the value from /dev/fb0 (i'm still in vt0). One symptom among other, unfortunately :-( > Do you have two Device sections ? If that doesn't work try setting the > FRAMEBUFFER environment variable. I have numerous Device sections, properly used in almost as numerous ServerLayout ; and I use startx -- -layout SomeLayout. The same Device/Layout used to work IIRC when I had only one card. But I should try again with the current X snapshot... -- romain |
|
From: Sven L. <lu...@dp...> - 2001-04-19 08:04:15
|
On Wed, Apr 18, 2001 at 04:57:58PM -0700, Miles Lane wrote: > "David S. Miller" wrote: > > > > James Simmons writes: > > > The Linux GFX project grew out the need for a higher performance X > > > server that has a much faster developement cycle. In the last few years > > > the graphics card and multimedia environments have grow at such a rate > > > the current X solutions can no longer keep pace nor do they focus on > > > producing high performance X servers specifically for linux. Also the > > > community has demanded for specific functionality which has never come to > > > light. > > > > And this specific functionality is? > > > > I think this is not a worthwhile project at all. The X tree, it's > > assosciated protocols and APIs, are complicated enough as it is, and > > the xfree86 project has some of the most talented and capable people > > in this area. It would be a step backwards to do things outside of > > xfree86 development. > > > > If the issue is that "things don't happen fast enough in the xfree86 > > tree", why not lend them a hand and submitting patches to them instead > > of complaining? > > Yes, David, I concur. > > James, please just pitch in and help XFree86 evolve faster. > There are drivers that need to be "Render" extension enabled. Sure, but if there was a Render documentation or something such, things would be much easier. > There's more work to do on fleshing out the Render extension. > I am sure that Kieth Packard would be grateful for any > worthwhile contributions. > > If you are thinking that you'll provide better accellerated > graphics rendering performance, I'd love to know how you plan > to accomplish this. AFAIK, the main impediment to XFree86 > giving really good accelleration support for a broad array > of hardware is the lack of technical documentation from the > manufacturers. Unless you plan on trying to get hardware Well, in doing fbdev drivers you already solve this kind of problems. > manufactures to have you develop their closed-source drivers > for them, I don't see how you'll be able to do any better closed source driver are evil anyway, so don't worry about those. > than the XFree86 organization is already doing. > > XFree86 evolves in a measured way as a result of many > competing needs. Backward compatibility is needed for the > huge installed base of legacy apps. For the various > development toolkits (KDE, Gnome, etc.) there is a rapid > move toward using the Render and "Resize and Rotate" > extensions. These extensions will make all sorts of cool > rendering functionality available to the applications that > use these toolkits (alpha blending, anti-aliased fonts and > so on). > > I'd love to hear you enumerate all the shortcomings that you > believe need to be addressed. Also, please CC: de...@xf.... > At least give the competition an opportunity to win over the > support of the developers you'd like to pull away from > XFree86 work! I think the main critic (guessing from his announcement) is the interaction between the console system and xfree86, as well as the multi-head/keyboard/whatever handling, but let's hear what james has to say about it. Friendly, Sven Luther |
|
From: Miles L. <mi...@me...> - 2001-04-18 23:57:33
|
"David S. Miller" wrote: > > James Simmons writes: > > The Linux GFX project grew out the need for a higher performance X > > server that has a much faster developement cycle. In the last few years > > the graphics card and multimedia environments have grow at such a rate > > the current X solutions can no longer keep pace nor do they focus on > > producing high performance X servers specifically for linux. Also the > > community has demanded for specific functionality which has never come to > > light. > > And this specific functionality is? > > I think this is not a worthwhile project at all. The X tree, it's > assosciated protocols and APIs, are complicated enough as it is, and > the xfree86 project has some of the most talented and capable people > in this area. It would be a step backwards to do things outside of > xfree86 development. > > If the issue is that "things don't happen fast enough in the xfree86 > tree", why not lend them a hand and submitting patches to them instead > of complaining? Yes, David, I concur. James, please just pitch in and help XFree86 evolve faster. There are drivers that need to be "Render" extension enabled. There's more work to do on fleshing out the Render extension. I am sure that Kieth Packard would be grateful for any worthwhile contributions. If you are thinking that you'll provide better accellerated graphics rendering performance, I'd love to know how you plan to accomplish this. AFAIK, the main impediment to XFree86 giving really good accelleration support for a broad array of hardware is the lack of technical documentation from the manufacturers. Unless you plan on trying to get hardware manufactures to have you develop their closed-source drivers for them, I don't see how you'll be able to do any better than the XFree86 organization is already doing. XFree86 evolves in a measured way as a result of many competing needs. Backward compatibility is needed for the huge installed base of legacy apps. For the various development toolkits (KDE, Gnome, etc.) there is a rapid move toward using the Render and "Resize and Rotate" extensions. These extensions will make all sorts of cool rendering functionality available to the applications that use these toolkits (alpha blending, anti-aliased fonts and so on). I'd love to hear you enumerate all the shortcomings that you believe need to be addressed. Also, please CC: de...@xf.... At least give the competition an opportunity to win over the support of the developers you'd like to pull away from XFree86 work! Miles |
|
From: Sven L. <lu...@dp...> - 2001-04-18 23:34:45
|
On Wed, Apr 18, 2001 at 11:58:32AM -0700, James Simmons wrote: > > I wanted to post a message about the new direction for my work is > going to take place. As many know my goals have been to rework the console > layer by reworking the fbdev layer and using the input api. Yes it is not > the most exciting project so I have had a slow development cycle. > The reason I started this project was to lay the foundations for a new > infra structure for X windows and to fix the many problems with X and the > console system. It would allow the devleopement of smaller leaner X servers. > I still like to do this. > Last night I meet with rasterman and discussed several issues about X > and linux with him. In the discussion I realized that I need to work at a > faster pace to help further the developement of linux as a graphical UNIX > system. So the console project and the work beind it will be merging with > the GFX project. Another project which I started to provide a open source > X server besides XFree86. XFree86 was not designed with linux in mind and > it as many people have felt has failed the linux community. So I like to > announce the start of the linux GFX project which we will begain work on a > new X server written from scratch. I plan to continue the work of the > console project. I'm just combining it with gfX server. Especially since > the X server input core will be written completely around the input api. > I will shortly send a message to the kernel mailing list. Thank you. Huh, ... you are forking the XFree86, is that the wisest course ? Do you have enough manpower and coding time as compared to the Xfree86 team ? Could you please explain a bit more about the reasons of this, and explain why it is a better course than working with the Xfree code, and adapting it to our needs. Also interresting would be to know what part of the X code you will be reusing, and what part of it you won't be reusing. Notice also that this sort of moves will not make the Xfree people more happy with fbdev stuff in general :((( Friendly, Sven Luther |
|
From: David S. M. <da...@re...> - 2001-04-18 22:12:42
|
James Simmons writes: > The Linux GFX project grew out the need for a higher performance X > server that has a much faster developement cycle. In the last few years > the graphics card and multimedia environments have grow at such a rate > the current X solutions can no longer keep pace nor do they focus on > producing high performance X servers specifically for linux. Also the > community has demanded for specific functionality which has never come to > light. And this specific functionality is? I think this is not a worthwhile project at all. The X tree, it's assosciated protocols and APIs, are complicated enough as it is, and the xfree86 project has some of the most talented and capable people in this area. It would be a step backwards to do things outside of xfree86 development. If the issue is that "things don't happen fast enough in the xfree86 tree", why not lend them a hand and submitting patches to them instead of complaining? Later, David S. Miller da...@re... |
|
From: James S. <jsi...@li...> - 2001-04-18 22:03:02
|
The Linux GFX project grew out the need for a higher performance X
server that has a much faster developement cycle. In the last few years
the graphics card and multimedia environments have grow at such a rate
the current X solutions can no longer keep pace nor do they focus on
producing high performance X servers specifically for linux. Also the
community has demanded for specific functionality which has never come to
light.
This project looks to start from scratch to develope a new X
enviroment that addresses these issues. I posted here because we will
addressing several issues about hardware management between the kernel
and the X window enevironment. Of course the X enrvironment is extremly
broad so this will require skills from several areas as well as many
programmers. So we welcome anyone how would like to see a alternative to
the current X implemenation. If you like to subscribe to our mailing
list just follow the link below. Thank you.
http://lists.sourceforge.net/lists/listinfo/linuxgfx-dev
|
|
From: James S. <jsi...@li...> - 2001-04-18 18:58:38
|
I wanted to post a message about the new direction for my work is
going to take place. As many know my goals have been to rework the console
layer by reworking the fbdev layer and using the input api. Yes it is not
the most exciting project so I have had a slow development cycle.
The reason I started this project was to lay the foundations for a new
infra structure for X windows and to fix the many problems with X and the
console system. It would allow the devleopement of smaller leaner X servers.
I still like to do this.
Last night I meet with rasterman and discussed several issues about X
and linux with him. In the discussion I realized that I need to work at a
faster pace to help further the developement of linux as a graphical UNIX
system. So the console project and the work beind it will be merging with
the GFX project. Another project which I started to provide a open source
X server besides XFree86. XFree86 was not designed with linux in mind and
it as many people have felt has failed the linux community. So I like to
announce the start of the linux GFX project which we will begain work on a
new X server written from scratch. I plan to continue the work of the
console project. I'm just combining it with gfX server. Especially since
the X server input core will be written completely around the input api.
I will shortly send a message to the kernel mailing list. Thank you.
|
|
From: Geert U. <ge...@li...> - 2001-04-18 10:22:04
|
The Epson 1355 frame buffer device doesn't use resource management (yet), so it
must be initialized later.
--- linux-2.4.4-pre4/drivers/video/fbmem.c.orig Wed Apr 18 11:40:40 2001
+++ linux-2.4.4-pre4/drivers/video/fbmem.c Wed Apr 18 12:17:57 2001
@@ -202,9 +202,6 @@
#ifdef CONFIG_FB_SIS
{ "sisfb", sisfb_init, sisfb_setup },
#endif
-#ifdef CONFIG_FB_E1355
- { "e1355fb", e1355fb_init, e1355fb_setup },
-#endif
/*
* Generic drivers that are used as fallbacks
@@ -269,6 +266,9 @@
#endif
#ifdef CONFIG_FB_HIT
{ "hitfb", hitfb_init, NULL },
+#endif
+#ifdef CONFIG_FB_E1355
+ { "e1355fb", e1355fb_init, e1355fb_setup },
#endif
#ifdef CONFIG_FB_DC
{ "dcfb", dcfb_init, NULL },
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
|
754 messages has been excluded from this view by a project administrator.
