Re: Error when usinf NCD Xterminal



Kevin Handy <kth srv net> writes: 
> > If nothing else you could perhaps rebuild GTK and pass
> > --with-xinput=no to configure, then it won't try to use xinput.
> 
> Any way to try it from the command line. I thought there were some
> options that could turn off various things. (This is from a RedHat
> 7.1 install, and trying to get the paths and versions correct on 
> everything installed is sometimes very difficult)

This would require recompiling GTK. To do that without giving up
package management, the rough steps are:
 
If you get the SRPM (on the source CD that comes with Red Hat Linux),
type "rpm -Uvh whatever.src.rpm", then edit /usr/src/redhat/gtk+.spec,
find the line that runs configure, it appears to have
--with-xinput=xfree in a version I'm looking at, change to
"--with-xinput=no", then "rpm -ba /usr/src/redhat/gtk+.spec", then
install the resulting gtk+ and gtk+-devel packages in
/usr/src/redhat/RPMS/i386/.

You may need to --force the install (and use rpm -i instead of rpm -U)
because the rebuilt RPM will have the same release number as the old
RPM. You could increment the release number in the spec file, but then
that might confuse the upgrader if you move to the next version of Red
Hat.

I'm assuming --with-xinput=no works, I haven't tried it myself. But it
looks like it should work.

> > If the terminal lists the extension but doesn't actually support it,
> > then that would certainly confuse GTK. (Or more accurately, it
> > probably confuses Xlib, but GTK is using the Xlib functions that use
> > this extension.) The X terminal is definitely badly broken if it does
> > this kind of false advertising, though.
> 
> NCD usually has a good reputation for their X terminals, and it would
> suprise me if they were broken this way.

All software has bugs, it doesn't necessarily reflect badly on them if
they make a mistake or two. Not many apps use the input extension so
they may not have tested this.

> Is there some way to test for this? If it is true, then I'd want to
> bug them about it, and try to get fixed software.

I don't know how to test it except to hack up some sample code and try
that, or get a gtk app in a debugger while running on one of these
terminals.
 
> Yes. This company has several models of X terminals (some color,
> some B&W), and it seems to work on all except the HMX terminals,
> which are of much more recent models than the others. The NCD's seem
> to all specify that they have XInputExtension in the xdpyinfo
> printout. Haven't looked closely at all of them, but those that I
> have show it.

I can't find the code where GTK checks for xinput support on the
server at runtime; if I could, I would be more sure the terminal is to
blame. Owen may understand better how GTK is supposed to work in this
respect and be able to say definitively whether gtk has been tested on
servers that lack the input extension and properly advertise that.

Havoc





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]