> > > > 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,
>
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 i
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 tryi
> 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 comin
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 sl
> > 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.
>
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 :
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
> > > 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
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 ge
> > 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 intrigu
>
> 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
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
comman
> > 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 o
> 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 alterna
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.
> > >
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
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 full
>
> 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 i
> 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
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 game
>> 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
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 gre
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 worth
25 matches
Mail list logo
