On 8/22/06, Richard Cooper <[EMAIL PROTECTED]> wrote:
The problem as I see it is that Linux uses fixed interval scheduling by configuring the timer chip to a fixed frequency. It would work much better if Linux used the timer in one-shot mode, simply setting it every time the interrupt calls the scheduler so that it times out the interval until the next time the scheduler needs to be called, but that seems to be yet another idea that has only ever occured to me.
_I_ always thought that was the sensible thing to do. A program is supposed to get a timeslice. Give it its timeslice. Linux uses the fixed timer for some other things, but they've become unnecessarily dependent on it. I think maybe they're trying to avoid the long I/O delays of accessing a hardware timer or something.
Actually, I've already figured out how to make this work, a year ago no less, when I wished to display video in 320x240x8, and found that it didn't work if the changing of the color palette wasn't synchronized with the changing of the image data. Worse than tearing, it just about looked as if the screen was full of static when one image's pixel data was shown with another image's palette. So I looked for a solution, found that once again I what I wanted to do was one of those things that you're just not supposed to do in Linux, so I did what I always do: I told everyone to fuck off and then I came up with my own solution:
Video synchronization is something that's such old news, I have trouble believing that it isn't one of the most basic functions of a video driver. Every graphics chip I know of has a vblank interrupt. A simple ioctl call to the kernel driver is all that's necessary: The driver puts the process to sleep and wakes it up on the interrupt, returning back form the ioctl.
kernel's scheduler used a one-shot timer, not only could run in user space without wasting 6% of the CPU, but it could do the same in the kernel, have its own API, and so root privledges wouldn't be necessary.
Your only problem is the lack of support from graphics drivers for a vblank interrupt. TROZ uses interrupts for various things, so we (Tech Source) had to write our own Linux kernel driver to support them so that when our X11 driver wanted to wait for the interrupt, it would just make an ioctl call. Zero wasted CPU time.
So, I don't know, maybe that counts as evidence that I just might know what I'm talking about. Linux can have good graphics, it's just that everyone, like yourself, has a lot of ignorant reasons why they believe it isn't possible.
Some of us just ignore the Linux kernel infrastructure entirely and do our own kernel driver. :)
I don't know... I guess I'm just a genius. I don't know how else to explain the lack of flexible scheduling, vertical syncing, and a graphics API. I guess I have solutions to all sorts of problems to which everyone else believes there is no solution. Maybe I need to help humanity by creating a web site to document everything that I believe to be common sense as apparently much of what I believe to be obvious isn't.
A number of people have managed to get seriously innovative ideas into the Linux kernel. Con Kolivas and Ingo Molnar are just two that come to mind. They developed new ideas, tested them, showed statistical evidence that their ideas were superior, dealt with all the flak they got wrt regressions, and then managed to get their stuff included in the kernel. When implementing their ideas, they quickly came face-to-face with the fact that their relatively simple concepts ended up touching on every aspect of the kernel. The only way to get their idea included was for them to make most or all of the necessary changes themselves. This takes a lot of dedication... and initiative.
I guess it's just a matter that I'm not allowed to have an easy solution to my graphics problems if you can't have an easy solution to yours.
There are other people who also know that aspects of the Linux kernel are utter crap. Many of them don't want to hear you mention them without offering the fix. It sounds like you're asking people to do work for them just to convenience you so that you can have things the way you want. Moreso than refusing to do what you ask, they're going to think you're a jerk for asking them to do work for you. That's not how Linux development works. The culture is such that you cannot make a suggestion unless it's a bugfix, you are providing code that does what you suggest, or you are participating in a discussion where someone else has asked for advice. You are perfectly-well allowed to have whatever solution you want... as long as you write it.
Saying that I can't have a VESA driver because not everyone can execute the VESA BIOS makes about as much sense as saying that I can't have a VESA driver because not every video card has a VESA BIOS.
That is not their objection. They object because there is not a compelling-enough reason for them to do it. If YOU wrote the VESA driver, they would probably be very happy to accept it (or they might resist, and you have to play some politics, but you can't blow your nose without someone somewhere raising SOME sort of objection). You gotta understand. I think your ideas are great. I'd love to implement them myself, but I just haven't the time! What can I do?
That's effectively what an x86 card with a VESA BIOS is in a non-x86 system. How does something as common sense as this manage to go so far over everyone's head? Yes, I forgot, I have no sense of what common sense is.
I think you're misreading the objections of the people who matter (who may not themselves be making objections), and you're taking too seriously the objections of other people who themselves don't know what they're talking about. Have you had Linus Torvalds or Alan Cox object to you directly? I would be surprised.
> You seem to despise a lot Linux' graphic support. Yet with > framebuffers a correctly written end user application can run on > any architecture you can think of. So what? The same could happen with all kinds of other APIs. Portability is nothing but a matter of never accessing anything directly and instead using generic functions and then creating one of those generic functions for every architecture you want to be portable to. Any piece of shit API can make applications portable and so the fact that Linux's framebuffer API helps to make applications portable doesn't mean that it isn't a piece of shit.
I think everyone would agree with you on this. Sometimes with a sensible system, you have to (or are allowed to) do something less than sensible under the hood for the sake of universality and portability.
What I want is an API that
Many other people want this too and would love you for providing it to them.
I fucking hate it when people mention portability.
Presentation problem. You mention the evil VESA up front, as though it's part of your primary motivation. No. Rather than saying, "I want VESA," you should say, "And BTW, as a side-effect, we can also write a generic VESA driver for this system as a stop-gap measure in order to get at least SOME support for cards until we have a proper native driver." That's the proper way to appeal to their sensibilities. You're leading people down the wrong path by mentioning things that are superfluous and not catering the least bit to their culture. Try doing business with the Japanese without understanding the ways they do business... they'll politely never talk to you again. You cannot expect people to listen to you if you do not speak their language (literally or figuratively). You're an outsider, making demands. That's going to get you kicked in the ass. You have no right to make demands! Who is going to listen to you when you show disrespect and contempt for them as people? That's what you're doing. Disrespecting people. People don't like to be disrespected. The solution is for you to show them proper respect, become one of them, show appreciation for their way of doing things, and show that you want to make a DIRECT contribution to their cause. Otherwise, go away.
software to use. I write the x86 version, someone with a Mac writes the Mac version, other people write other versions, and when we're all done, any software which uses my API is portable to any of those systems because it can just use the version of my graphics system available on those systems because they all use the same API.
You don't need to make it portable. You just have to demonstrate an eye towards making it portable. The minimum necessary is often comments in your code where you point out that you're doing something nonportable and why. People respect prototype code. You just have to show it to be a prototype. Free Software culture has a hierarchy. If you're a newbie, you have to show respect. Only once you've reached guru or samurai status can you tell other people what to do. Even then, they don't have to listen to you!
That's how portability works, but I can't get that into anyone's head.
What you mean and what they perceive are different things because you're not accounting for what they will perceive. They perceive that you don't give a damn at ALL about portability. Since portability is an immutable part of their culture, not bowing to it will make people think you're ignorant. Also, people realize that existing things are nonportable and they don't like it. They want to change it and are working gradually to fix it. The last thing they need is for some new person who doesn't understand portability (their perception) trying to introduce yet another nonportable thing.
I'm not thinking of 3D. I'm thinking of ordinary graphics modes with no acceleration. I couldn't care less about 3D. I'm pissed that Linux screws up everything related to graphics, even the simple stuff. When the simple stuff works, then I'll consider being pissed that the more complex stuff doesn't work.
Most people think that ignoring acceration is a very bad idea. I can list many. In other threads, I already have recently. You are demanding a sensible API. But what you're demanding, in detail, is not a sensible API. Or not a complete one. And if what you want is an early-generation partial API that improves things a lot but doesn't fix everything, then SAY SO. But you have to demonstrate that you fully understand all of the drawbacks to your implementation. Evolutionary approaches are more easily accepted than revolutionary ones. And the open source development model makes it easier to do things in an incremental way, because you have access to the source code for all of the drivers that would have to change when your API goes to the next version.
If you had thought about what I was saying you would realize that the point I was making was that graphics in Linux shouldn't be so difficult that it costs 20% of the development costs to support Linux.
I agree. A sensible API would dramatically reduce this cost. People don't have to retest X11 apps on every platform, because X11 is a standard, portable API.
As far as distributions and different versions of libc go, neither one matter if you do things correctly. Just create executables that aren't dependant on external resources and you'll have a binary that runs on every x86 Linux system.
Bad, bad, bad. You do not want to start advocating statically-linked executables. Massive bloat. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
