All,
I use GUIs in user space that are running under xwindows and I have not seen any
problems with my rtlinux modules or the GUI programs. I share the data between
rtlinux and linux using shared memory and rt-fifos without any problem. Can those who
have seen problems elaborate on the symptoms so that I may perform more tests and
determine if there is a problem I have not detected. Maybe I just have not tested
with tasks that take enough time to cause the problem. Usually my tasks run at a 1 ms
rate and therefore there is free cpu time in every 1 ms block of time.
For those interested I have been using LabView for linux to provide the GUI interface.
I have heard of others using Qt.
Thanks,
Rich
-----Original Message-----
From: Dan Peters [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 21, 2001 8:57 AM
To: [EMAIL PROTECTED]
Subject: Re: [rtl] user space program hangs
David Olofson wrote:
> On Saturday 18 August 2001 09:36, Herman Bruyninckx wrote:
> > On Fri, 17 Aug 2001, Dan Peters wrote:
> >
> > [...]
> >
> > > I believe it all has to do somehow with interrupting X calls. Do
> > > you have any experience with running X under rtlinux? I have work
> > > with X many times in a non RT environment and have not had these
> > > problems. Is there a better alternative to running X for doing
> > > graphical stuff under RT linux.
> >
> > Don't use X!
>
> Or make sure you've got a properly configured X server and a video card
> with a decent driver... Some work, but shouldn't by a major issue if you
> need RTLinux on the machine in the first place. (You don't run RTLinux on
> the average workstation anyway.)
The video chip is a C&T 65550, and as far as I know, the server has been
configured properly.
This is part of a control system, which I feel needs RTlinux. The only
reason to use X is to display an image and
display some other data on a display. Are there any better alternatives to
X.
>
>
> > Unless you know exactly what your X driver is doing...
> > The polygons-rendered-per-second race of card manufacturers makes many
> > drivers behave _very_ unfriendly towards other processes (disabling
> > interrupts for too long etc.)
>
> Yeah. Some of this can be fixed by configuring the server properly,
> though. (AFAIK, very few cases are actually hardware problems. Even this
> debated PCI bus stall is a driver bug - some drivers allow the card to
> block the bus, rather than checking the command FIFO status before
> writing.)
>
> //David Olofson --- Programmer, Reologica Instruments AB
>
> .- M A I A -------------------------------------------------.
> | Multimedia Application Integration Architecture |
> | A Free/Open Source Plugin API for Professional Multimedia |
> `----------------------------> http://www.linuxdj.com/maia -'
> .- David Olofson -------------------------------------------.
> | Audio Hacker - Open Source Advocate - Singer - Songwriter |
> `--------------------------------------> [EMAIL PROTECTED] -'
>
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> --
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
