The only real way to do this "right" is going to be to have the X
server load a KLD, which will then be able to hook the relevant
interrupt(s). Any other alternative involves interrupt delivery to
user-space, which is just not practical.
Hi Mike,
Your idea sounds
Say is there anyone that can add signal delivery to the /sys/dev/fb/vga.c?
(For now any quick hack to the driver for delivering the signal will do )
The context is from a posting to the xfree86 mailing list:
[EMAIL PROTECTED] said:
You need to fit one event in per retrace. If you knew
Is all this just because some of the new video HW are crappy, ie that
they produce snow/flicker/whatever (like in the old CGA days) or is
this a genuine problem, as I said above I've never seen any problems
on my ATI cards, and my laptop doesn't have this either (neomagic)..
Yes, this is a
AFAIK, not all video cards generate the vertical retrace interrupt.
Even worse, some BIOSes have a configuration option which instract the
BIOS NOT to assign an IRQ to the PCI video card.
I fully agree that the vertical retrace interrupt will be of great
value, but I wonder if it is really
Well, I may be wrong :-)
Well, sortof :)
The delay caused by the system to process the interrupt and deliver
the signal etc is unpredictable (well sortof) and is almost certainly
too long so the window of opportunity will be missed ...
This has been discussed to death many times in the past
Kazutaka YOKOTA wrote:
I fully agree that the vertical retrace interrupt will be of great
value, but I wonder if it is really worth the trouble, because it might
be available in only few cards and systems at the end of the day...
I may have value synchronizing animation, such as games.
It seems Kazutaka YOKOTA wrote:
AFAIK, not all video cards generate the vertical retrace interrupt.
Even worse, some BIOSes have a configuration option which instract the
BIOS NOT to assign an IRQ to the PCI video card.
I fully agree that the vertical retrace interrupt will be of
AFAIK, not all video cards generate the vertical retrace interrupt.
Even worse, some BIOSes have a configuration option which instract the
BIOS NOT to assign an IRQ to the PCI video card.
I fully agree that the vertical retrace interrupt will be of great
value, but I wonder if it is
It seems Amancio Hasty wrote:
It seems Kazutaka YOKOTA wrote:
AFAIK, not all video cards generate the vertical retrace interrupt.
Even worse, some BIOSes have a configuration option which instract the
BIOS NOT to assign an IRQ to the PCI video card.
I fully agree that the
What will happen if the X server was running with real time priorities which
syncing up with a vertical retrace seems to imply?
--
Amancio Hasty
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Thu, 4 Nov 1999, Amancio Hasty wrote:
It seems Kazutaka YOKOTA wrote:
AFAIK, not all video cards generate the vertical retrace interrupt.
Even worse, some BIOSes have a configuration option which instract the
BIOS NOT to assign an IRQ to the PCI video card.
I fully agree
What will happen if the X server was running with real time priorities which
syncing up with a vertical retrace seems to imply?
The only real way to do this "right" is going to be to have the X
server load a KLD, which will then be able to hook the relevant
interrupt(s). Any other
On 05-Nov-99 Amancio Hasty wrote:
Your idea sounds intriguing . How should we wired the KLD to
the X server? or how will the KLD inform the X server that it
has received a vertical retrace interrupt .
It depends what you wanted to do, but you could have the X server feed the KLD
commands
On 05-Nov-99 Amancio Hasty wrote:
Your idea sounds intriguing . How should we wired the KLD to
the X server? or how will the KLD inform the X server that it
has received a vertical retrace interrupt .
It depends what you wanted to do, but you could have the X server feed the KLD
The only real way to do this "right" is going to be to have the X
server load a KLD, which will then be able to hook the relevant
interrupt(s). Any other alternative involves interrupt delivery to
user-space, which is just not practical.
Hi Mike,
Your idea sounds intriguing . How
On 05-Nov-99 Amancio Hasty wrote:
Not sure that this is as elegant as what you are suggesting , can
the kernel schedule a user level routine to be executed when an interrupt
occurs? I guess on Windoze land this is called a driver call-back.
Well.. KLD? :)
Thats about as close as it
The only real way to do this "right" is going to be to have the X
server load a KLD, which will then be able to hook the relevant
interrupt(s). Any other alternative involves interrupt delivery to
user-space, which is just not practical.
Hi Mike,
Your idea sounds intriguing
Amancio Hasty wrote:
Not sure that this is as elegant as what you are suggesting , can
the kernel schedule a user level routine to be executed when an interrupt
occurs? I guess on Windoze land this is called a driver call-back.
Under UNIX it's called a signal handler :-)
- mark
It seems Amancio Hasty wrote:
Just trying to prevent dragging the whole X server to the kernel --
Actually dragging the whole X server to the kernel is not a bad
idea --- however it is something that I can not afford to do right now :(
Ahh, horror, Terry's old idea is coming back again :)
Kind of complex though. Also the interrupt latency problem is still there.
Not sure that this is as elegant as what you are suggesting , can
the kernel schedule a user level routine to be executed when an interrupt
occurs? I guess on Windoze land this is called a driver call-back.
On 05-Nov-99 Kevin Day wrote:
This works, but still has a problem if latency and missed interrupts if you
aren't reading when the interrupt happens. (I've worked around those too,
but that's quite a bit more involved to fix it). You'll probably need to end
up changing the scheduler
It seems Amancio Hasty wrote:
Lets step back for a moment, this is clearly the wrong solution to
everything, what exactly is it you want to do or want to accomplish??
Lets see if we can come up with another way of doing that...
Okay,
The problem that the XFree86 group is trying to
22 matches
Mail list logo
