Re: 2 yo hp monitor, old dell, no video

[gene heskett]

On 8/19/22 21:38, Felix Miata wrote:

gene heskett composed on 2022-08-16 19:08 (UTC-0400):


I bought two of these monitors around 20 months back when they were on
sale at Staples. This one works great
on a newer ASUS mb & debian bullseye. 1920x1080, no xorg.conf.
The 6 or 8 yo AOC 1366x768 I've been using on an older dell OptiPlex
7010DT to drive my 3d printers
went black today so I unpacked the other monitor.
This dell has a db15 output with an hdmi plug on the other end of the
cable. Its menu's work, but it
can't find a signal.
Does this dells video need a special driver to hit it with a 1920x1080
signal.
Xorg.0.log from the Dell attached.

No special driver is available or required AFAIK.

I've never known an analog 15-pin VGA PC output to be able to communicate fully
with a display via a display's HDMI input. I suppose there may be some sort of
non-passive way to do this, but the VGA to HDMI cable you have probably isn't 
any
such thing. Digital output to analog input /is/ typically possible with an
inexpensive passive adapter or adapter cable.

Optiplexes usually have also a DisplayPort output. They can be used with a 
passive
adapter to connect to a display's HDMI or DVI port.


Describe a "display port" socket, please, Felix.  If you've the time.

This db15 to hdmi cable had been working quite normally for about 2 
years, but the monitor
was not plugged into  the ups the Dell was, and we had some noisy 
weather in the night
Tuesday night, no video the next morning. I live alone now, and I did 
not get up in the night to

move any cables.

Now I have a rock64, 4GB V2, running octoprint, better display than that 
AOC was by far.

And its all plugged into the same ups now.

However, that means cura has to run on this machine to generate the 
gcode octoprint feeds
the printers with. But cura can't see a dotted directory, so there's a 
third step between my ideas

in OpenSCAD, and getting the code into octoprints input buffer.

The dells SSD should be pulled, a startech usb3 to sata adapter added 
and put on the rock64
for a work disk. The 64GB pnc its booting from now is not noted for 
either speed or longevity.


Thank you, Felix,  take care and stay well please.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

2 yo hp monitor, old dell, no video

[gene heskett]

Greetings folks;

I bought two of these monitors around 20 months back when they were on 
sale at Staples. This one works great

on a newer ASUS mb & debian bullseye. 1920x1080, no xorg.conf.

The 6 or 8 yo AOC 1366x768 I've been using on an older dell OptiPlex 
7010DT to drive my 3d printers

went black today so I unpacked the other monitor.

This dell has a db15 output with an hdmi plug on the other end of the 
cable. Its menu's work, but it

can't find a signal.

Does this dells video need a special driver to hit it with a 1920x1080 
signal.

Xorg.0.log from the Dell attached.

Thank you for any insight on this.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>
[ 3.502] 
X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
[ 3.502] Build Operating System: linux Debian
[ 3.502] Current Operating System: Linux dddprint 5.10.0-16-amd64 #1 SMP Debian 5.10.127-2 (2022-07-23) x86_64
[ 3.502] Kernel command line: BOOT_IMAGE=/vmlinuz-5.10.0-16-amd64 root=UUID=f3fcee6c-d295-43fb-b0d2-5e014b16ab9e ro quiet
[ 3.502] Build Date: 05 August 2022  08:00:36AM
[ 3.502] xorg-server 2:1.20.11-1+deb11u2 (https://www.debian.org/support) 
[ 3.502] Current version of pixman: 0.40.0
[ 3.502] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[ 3.502] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 3.502] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Aug 16 18:16:07 2022
[ 3.504] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 3.506] (==) No Layout section.  Using the first Screen section.
[ 3.506] (==) No screen section available. Using defaults.
[ 3.506] (**) |-->Screen "Default Screen Section" (0)
[ 3.506] (**) |   |-->Monitor ""
[ 3.507] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
[ 3.507] (==) Automatically adding devices
[ 3.507] (==) Automatically enabling devices
[ 3.507] (==) Automatically adding GPU devices
[ 3.507] (==) Max clients allowed: 256, resource mask: 0x1f
[ 3.509] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 3.509] 	Entry deleted from font path.
[ 3.513] (==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins
[ 3.513] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 3.513] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[ 3.513] (II) Loader magic: 0x56472cfe4e40
[ 3.513] (II) Module ABI versions:
[ 3.513] 	X.Org ANSI C Emulation: 0.4
[ 3.513] 	X.Org Video Driver: 24.1
[ 3.513] 	X.Org XInput driver : 24.1
[ 3.513] 	X.Org Server Extension : 10.0
[ 3.513] (++) using VT number 7

[ 3.513] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
[ 3.514] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 3.531] (--) PCI:*(0@0:2:0) 8086:0152:1028:0577 rev 9, Mem @ 0xf780/4194304, 0xe000/268435456, I/O @ 0xf000/64, BIOS @ 0x/131072
[ 3.536] (II) LoadModule: "glx"
[ 3.537] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 3.547] (II) Module glx: vendor="X.Org Foundation"
[ 3.547] 	compiled for 1.20.11, module version = 1.0.0
[ 3.547] 	ABI class: X.Org Server Extension, version 10.0
[ 3.547] (==) Matched modesetting as autoconfigured driver 0
[ 3.547] (==) Matched fbdev as autoconfigured driver 1
[ 3.547] (==) Matched vesa as autoconfigured driver 2
[ 3.547] (==) Assigned the driver to the xf86ConfigLayout
[ 3.548] (II) LoadModule: "modesetting"
[ 3.548] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 3.549] (II) Module modesetting: vendor="X.Org Foundation"
[ 3.549] 	compiled for 1.20.11, module version = 1.20.11
[ 3.549] 	Module class: X.Org Video Driver
[ 3.549] 	ABI class: X.Org Video Driver, version 24.1
[ 3.549] (II) LoadModule: "fbdev"
[ 3.549] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[ 3.549] (II) Module fbdev: vendor="X.Org Foundation"
[ 3.550] 	compiled for 1.20.0, module version = 0.

Re: R128 errors

[Gene Heskett]

On Sunday 23 May 2021 14:33:27 Chris Fisichella wrote:

> Hi,
>
> I am coming off of a previous post where I had just a black screen.
> That has changed. I can now access my Xorg.0.log file. It is attached.
>
And it looks like it gave it the old college try.  And I don't see on a 
32 bit system, any reason why the address reported as out of range in 
the EE lines, should be out of range.

> If anyone who is familiar with the R128 driver can help debug what I
> need to do, I would appreciate it.
>
> The computer is a 32 bit machine. The video card is the ATI
> ALL-IN-WONDER 128 PRO. The operating system is Debian 10.9.0.

What I do get the impression of, is that you are doing battle with a 
frankenstein card, something ati has been quite famous for in my now 20+ 
year old history, changing the card in the box, making it incompatible 
with the published drivers for linux, without updateing a single crossed 
t or dotted i on the box. Plain and simple it was not the card I bought 
but the next production run. I yelled at ati, and was promised linux 
drivers for that chipset would be announced in about 2 weeks. Never 
happened, and I wasted almost $85 running out to buy it in about 1999.

At least the $29 nvidia card worked with the vesa driver. But that 
experience taught me to not believe a thing Alex tells me. YMMV.

> The driver seems to be identifying the card okay. I don't know why it
> is still generating errors. Any ideas?
>
> Best Regards,
> Chris


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Colour cycling / Dell monitor service menu (was: Feature request, but must be universallly accepted by ALL blanker authors)

[Gene Heskett]

On Sunday 04 October 2020 23:50:42 Adam Nielsen wrote:

> > It turns out that the color cycling screen was that old 17" 4x3 Dell
> > lcd monitors response to the synch drop that shuts most modern
> > monitors off.
>
> Someone has probably enabled burnin test mode on this monitor.  The
> method to switch it on and off is pretty much the same on all Dell
> monitors.
>
> Switch the monitor off with the power button on the front panel, then
> hold the 'menu' and '+' buttons at the same time while you press
> 'power' to turn it on again.  Keep holding both 'menu' and '+' while
> the screen is blank, letting go a few seconds later once the normal
> display appears.  This brings the monitor up in service mode.
>
> When in service mode (depending on model) you can press the '+' or '-'
> buttons to bring up the service menu, or on older monitors you have to
> go into the normal menu (which now displays some additional model and
> firmware version numbers, confirming you're in service mode) and go to
> the 'factory reset' option.  Normally the factory reset menu gives you
> a submenu with yes/no options, but with service mode active you get a
> third menu option that will take you to the service menu.
>
> In the service menu, look for the option called 'Burnin mode' or
> similar and switch it off.  This will cause the monitor to actually go
> into powersaving mode when there is no signal, rather than go through
> the colour cycling test mode you're seeing.
>
> Once you've made your changes, exit the menu and switch the monitor
> off and on again with the front panel power button to exit service
> mode.
>
> Cheers,
> Adam.

Thank you Adam. Printed and carried up the hill to the shop for 
prompting. I spotted it, looking pretty new, at a yard sale nearly 20 
years ago, and brought it home for a $20 bill. Its been above and behind 
a CNC'd 7x12 lathe ever since, but the lexan sheet in front of it is 
much the worse for hot flying swarf.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Feature request, but must be universallly accepted by ALL blanker authors

[Gene Heskett]

On Sunday 04 October 2020 15:10:03 Alan Coopersmith wrote:

> On 10/3/20 1:08 AM, Gene Heskett wrote:
> > On Friday 02 October 2020 16:28:45 Alan Coopersmith wrote:
> >> Fortunately, there's already an existing script which knows about
> >> the most common screensaver implementations and how to suspend
> >> them:
> >>
> >> https://linux.die.net/man/1/xdg-screensaver
> >> https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/
> >>xdg -screensaver.in
> >>
> >> So LinuxCNC could call xdg-screensaver suspend with the ID of its
> >> control window.
> >
> > On the machines own monitor, isn't that display 0:0?
> >
> :0.0 is the display, not the window.  "xwininfo -tree -root" will list
> : all
>
> the window ids on that display.
>
> > Example command line please?
>
>   xdg-screensaver suspend `xwininfo -name xlogo | awk '/Window id/
> {print $4}'`
>
> But if LinuxCNC is calling it directly, it knows its own window ids
> already and doesn't have to use xwininfo to find them.

Linuxcnc has neveer called anything like that directly. But it is 
launched by mostly python scripts that could be edited to add it.
And I finally got enough of the xfce4-goodies installed to get the 
ability to control it via the settings menu, and have successfully 
turned it all off.

It turns out that the color cycling screen was that old 17" 4x3 Dell lcd 
monitors response to the synch drop that shuts most modern monitors off.

The fly in the login soup was that particular login greeters total 
non-indication that a passwd was being entered. That keyboard has a 
custom fitted swarf cover that makes error free typeing a much sought 
after endeavor and I never write code using it, but punching it in one 
character at time rather violently seems to work. Since I am normally 
alone, that advertising of the passwd is a non-worry. I've taken to 
locking up at night, along with some signage promising response to 
prowlers in lead, should take care of the security if they can read...

Thanks Alan.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Feature request, but must be universallly accepted by ALL blanker authors

[Gene Heskett]

On Saturday 03 October 2020 05:25:50 Vladimir Dergachev wrote:

> On Sat, 3 Oct 2020, Gene Heskett wrote:
> >> which suggests there are several ways to disable it, including one
> >> where you can simulate user activity.
> >>
> >> This was just a quick look, it would probably be best to talk to
> >> light-locker developers.
> >>
> >> best
> >>
> >> Vladimir Dergachev
> >
> > And where might I find those folks?
>
> Try contacting developers listed in
>
> https://github.com/the-cavalry/light-locker/blob/master/MAINTAINERS
>
emailed both, thank you Vladimir.

> Vladimir Dergachev
>
> > Thank you Vladimir.
> >
> > Cheers, Gene Heskett
> > --
> > "There are four boxes to be used in defense of liberty:
> > soap, ballot, jury, and ammo. Please use in that order."
> > -Ed Howdershelt (Author)
> > If we desire respect for the law, we must first make the law
> > respectable. - Louis D. Brandeis
> > Genes Web page <http://geneslinuxbox.net:6309/gene>
> > ___
> > xorg@lists.x.org: X.Org support
> > Archives: http://lists.freedesktop.org/archives/xorg
> > Info: https://lists.x.org/mailman/listinfo/xorg
> > Your subscription address: %(user_address)s
>
> _______
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Feature request, but must be universallly accepted by ALL blanker authors

[Gene Heskett]

On Saturday 03 October 2020 04:17:53 Vladimir Dergachev wrote:

> On Sat, 3 Oct 2020, Gene Heskett wrote:
> > On Saturday 03 October 2020 00:39:27 Vladimir Dergachev wrote:
> >> On Fri, 2 Oct 2020, Gene Heskett wrote:
> >>> Greetings x-people;
> >>>
> >>> The LinuxCNC people have just brought it up from Debian wheezy to
> >>> buster for a base install.
> >>>
> >>> But the security paranoia is going to get someone maimed or
> >>> killed.
> >>>
> >>> Someone has decreed that the screen blanker must be subject to a
> >>> new login before anything can be done about a runaway machine with
> >>> enough horsepower at its disposal to kill.
> >>
> >> Just to chime in, this is not an X problem per se, but rather the
> >> desktop environment.
> >
> > Agreed.
> >
> >> X does not have a utility to ask for your password - just a way to
> >> blank the screen and turn off the monitor.
> >>
> >> If you were to prevent X from blanking the screen, then what would
> >> likely happen is that it will not go blank, but instead you will
> >> see either a screensaver or a password prompt from whatever screen
> >> locker your desktop environment is using.
> >
> > Which for xfce4 is light-locker. But removing it with apt destroys
> > the system by removeing 70+ other packages including ours.  Thats
> > not an acceptable solution.
>
> This is surprising. It is hard for me to see why your package - or any
> package - would depend on a screensaver. I would normally expect only
> the meta package that pulls in the full environment to depend on it.
>
> > FWIW, I have tried mightily, to lengthen the intervals from 10
> > minutes on this stretch install running TDE. But something resets it
> > to 10 minutes before the 10 minutes is up. So xset is neutered and
> > worthless. Frankly, linux is as bad as winderz in determining what
> > you can and cannot do. If there was an alternative that put the
> > machines control back in the uses hands, I'd jump on it like stink
> > on a skunk.
>
> Looking on github, I found the following file
>
> https://github.com/the-cavalry/light-locker/blob/master/src/light-lock
>er-command.c
>
> which suggests there are several ways to disable it, including one
> where you can simulate user activity.
>
> This was just a quick look, it would probably be best to talk to
> light-locker developers.
>
> best
>
> Vladimir Dergachev

And where might I find those folks?

Thank you Vladimir.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Feature request, but must be universallly accepted by ALL blanker authors

[Gene Heskett]

On Friday 02 October 2020 16:28:45 Alan Coopersmith wrote:

> On 10/2/20 12:18 PM, Gene Heskett wrote:
> > I have now been 3 days looking for a way to disable this blanker,
> > trying several methods by way of xset, only to find 15 minutes later
> > that its been undone and the blanker kicks in regardless.
>
> xset only controls the screen blanking & power management built into
> the X server.  Anything prompting for a password to unlock is from a
> client application or window manager/desktop environment, not the X
> server, and has its own controls.  (For GNOME 3, this is built into
> gnome-shell & gdm, for other environments it may be a standalone
> program like xscreensaver or xlockmore.)
>
> > So I am proposing that an env variable be named an agreed upon name,
> > and that its presence totally disables any and ALL screen blanker's
> > regardless of whose desktop of the day is installed.  We can
> > incorporate the setting of this, on launching LinuxCNC, and
> > unsetting it when LinuxCNC is being shut down.
>
> I don't see how LinuxCNC could set an environment variable that will
> be detected by programs that started before LinuxCNC was - normally
> environment variables are passed on from the process that starts
> another process and there's no common API to change one in an already
> running process.
>
> Fortunately, there's already an existing script which knows about the
> most common screensaver implementations and how to suspend them:
>
> https://linux.die.net/man/1/xdg-screensaver
> https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg
>-screensaver.in
>
> So LinuxCNC could call xdg-screensaver suspend with the ID of its
> control window.

On the machines own monitor, isn't that display 0:0?

Example command line please?

Thanks Alan.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Feature request, but must be universallly accepted by ALL blanker authors

[Gene Heskett]

On Saturday 03 October 2020 00:39:27 Vladimir Dergachev wrote:

> On Fri, 2 Oct 2020, Gene Heskett wrote:
> > Greetings x-people;
> >
> > The LinuxCNC people have just brought it up from Debian wheezy to
> > buster for a base install.
> >
> > But the security paranoia is going to get someone maimed or killed.
> >
> > Someone has decreed that the screen blanker must be subject to a new
> > login before anything can be done about a runaway machine with
> > enough horsepower at its disposal to kill.
>
> Just to chime in, this is not an X problem per se, but rather the
> desktop environment.
>
Agreed.

> X does not have a utility to ask for your password - just a way to
> blank the screen and turn off the monitor.
>
> If you were to prevent X from blanking the screen, then what would
> likely happen is that it will not go blank, but instead you will see
> either a screensaver or a password prompt from whatever screen locker
> your desktop environment is using.

Which for xfce4 is light-locker. But removing it with apt destroys the 
system by removeing 70+ other packages including ours.  Thats not an 
acceptable solution.

FWIW, I have tried mightily, to lengthen the intervals from 10 minutes on 
this stretch install running TDE. But something resets it to 10 minutes 
before the 10 minutes is up. So xset is neutered and worthless. Frankly, 
linux is as bad as winderz in determining what you can and cannot do. If 
there was an alternative that put the machines control back in the uses 
hands, I'd jump on it like stink on a skunk.

> So the issue is really with the desktop environment you are using -
> there should be a control to disable screenlocker.
>
> I am using KDE on my laptop and it does have it.
>
> My CNC machine is controlled from Jetson nano, and I was able to
> disable password prompt, but the screensaver does kick in and I have
> to muck around with monitor control key to turn it back on, as the
> monitor touchscreen turns off with the monitor.
>
> best

To you too Vladimir.

> Vladimir Dergachev

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Feature request, but must be universallly accepted by ALL blanker authors

[Gene Heskett]

On Friday 02 October 2020 19:55:53 Aaron Plattner wrote:

> On 10/2/20 1:17 PM, Dan Arena wrote:
> > Gene,
> >
> > Following up more about xfce4, you should be able to go into their
> > Settings Manager and you can turn off the Screensaver and uncheck
> > Power Management under the Advanced tab. You will still want to add
> > the lines I mentioned before into /etc/X11/xorg.conf to prevent the
> > screen from going blank though.
> >
> > I also think it would be a useful feature for LinuxCNC to include an
> > option where it itself can prevent screensavers. This would not be
> > too hard for them to do, see
> > https://stackoverflow.com/a/31504731/1941627
> >
> > A friend also just brought up a good point... do these machines not
> > have a physical emergency stop button? It seems like with them being
> > as dangerous as you say they are, they should. I know the couple
> > mills I have seen do.
>
> I agree with this. There are so many things that could go wrong
> between the keyboard and software commanding the machine to stop
> (swapping prevents something from getting scheduled, interrupt storm
> from a rogue device delays processing, etc.). If this is really a
> safety critical feature then everything in the system along this path
> needs to have realtime guarantees, redundancy, and follow something
> like MISRA coding standards.
>
> It would be *way* easier and cheaper to put a big red stop button on
> the machine itself, and bypass this problem of screen locking programs
> entirely.
>
> I would not recommend relying on the computer for this.

This is quite true, and if it can't be fixed, I will be forced to install 
a smash it switch that interrupts machine power.  But I've some pretty 
high cap supplies that can keep it moving for several seconds after the 
switch has been fisted.  A software e-stop OTOH can stop it dead in the 
water in a very few milliseconds. 5 maybe. The diff might be 50 bucks 
worth of smashed tooling for me.  And $2000+ for a similar screwup at 
Toyota, who carves their lease only high output TRO engines for the 
racers with this same SW. Or were, they've taken down the youtube video 
as it was showing things they didn't want the joe six-packs copying.


Thanks Aaron.
>
> > I would also take this issue up with the LinuxCNC community. Is it
> > supposed to work like that? Does a new install from the LinuxCNC
> > "Install DVD" behave the same?

At the instant yes, Andy has an install patched and running, and if it's 
still working in the morning he'll respin the install iso tomorrow. But 
his patch is not working for me, yet.

> > Thanks,
> > Dan


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Feature request, but must be universallly accepted by ALL blanker authors

[Gene Heskett]

On Friday 02 October 2020 15:54:30 Dan Arena wrote:

> Good afternoon Gene,
>
> I am not sure about xfce, I suspect they do have settings in their GUI
> settings manager to adjust what you want, but seeing as this is the
> xorg mailing list I will tell you how I do it when running just X with
> a simple window manager. This is probably what you want. I put these
> lines into my /etc/X11/xorg.conf file on an appliance-like system for
> non-linux users. The first two settings DontVTSwitch and DontZap
> aren't actually related to "screen blanking", they prevent you from
> using ctrl+alt+f1 and ctrl+alt+backspace. You can delete them if you
> want.
>
> Section "ServerFlags"
> Option "DontVTSwitch" "on"
> Option "DontZap"  "on"
> Option "BlankTime" "0"
> Option "StandbyTime" "0"
> Option "SuspendTime" "0"
> Option "OffTime" "0"
> EndSection
>
>
> Anyways, thanks for the entertaining email.

I didn't really intend for it to be entertaining. My machines are limited 
to a couple horsepower, but there are folks on that mailing list with 
50+ horsepower spindle motors, so I was serious in my use of maimed or 
killed.

The above I assume is best tested after a reboot? But I don't see an 
xorg.conf file in the /etc/X11 directory. Debian 10, I have this:
gene@lathe:/etc/X11$ ls -l
total 76
drwxr-xr-x 2 root root  4096 Sep 29 15:06 app-defaults
-rw-r--r-- 1 root root18 Sep  7 06:40 default-display-manager
drwxr-xr-x 6 root root  4096 Sep 29 15:06 fonts
-rw-r--r-- 1 root root 17394 Nov 23  2016 rgb.txt
drwxr-xr-x 2 root root  4096 Sep 29 15:06 xinit
drwxr-xr-x 2 root root  4096 Feb 11  2019 xkb
-rwxr-xr-x 1 root root   709 Nov 23  2016 Xreset
drwxr-xr-x 2 root root  4096 Sep 29 15:06 Xreset.d
drwxr-xr-x 2 root root  4096 Sep 29 15:06 Xresources
-rwxr-xr-x 1 root root  3517 Nov 23  2016 Xsession
drwxr-xr-x 2 root root  4096 Sep 29 16:07 Xsession.d
-rw-r--r-- 1 root root   265 Nov 23  2016 Xsession.options
drwxr-xr-x 2 root root  4096 Sep 29 15:06 xsm
-rw-r--r-- 1 root root13 Dec  5  2016 XvMCConfig
-rw-r--r-- 1 root root   630 Sep  7 06:40 Xwrapper.config


> Happy Friday!

Day of the week is only important if its sunday as I'm a DM-II, and I 
shoot myself with bidureon on Sundays, and Wednesdays are trash 
collection pickups about dawn on Thursdays. Being retired for 17+ years, 
the rest of the week is a blur. Somewhat explainable by the fact I'll be 
86 yo by the time the next week gets started good. :)  And I don't see a 
good candidate in the list above.

I wonder what would happen if I just create that file and reboot?, 
done. /var/log/Xorg.0.log exists, and it must have been read as all that 
stuff is 0 in the Xorg.0.log. htop says lightdm-greeter is running for 
the initial login. zero X showing in htop.  Go up the hill and see since 
the monitor is in fact turned off till I turn it on. Which I did. Didn't 
bither it a bot. 11 minutes later I'm looking at a color cycling screen, 
and when I move the mouse, I'm looking at the lightdm-greeter login 
requester.

Next?  Or was that our best shot?

Thanks Dan A.

> -Dan
>
> On Fri, Oct 2, 2020 at 3:30 PM Gene Heskett  
wrote:
> > Greetings x-people;
> >
> > The LinuxCNC people have just brought it up from Debian wheezy to
> > buster for a base install.
> >
> > But the security paranoia is going to get someone maimed or killed.
> >
> > Someone has decreed that the screen blanker must be subject to a new
> > login before anything can be done about a runaway machine with
> > enough horsepower at its disposal to kill.
> >
> > I have now been 3 days looking for a way to disable this blanker,
> > trying several methods by way of xset, only to find 15 minutes later
> > that its been undone and the blanker kicks in regardless.
> >
> > So I am proposing that an env variable be named an agreed upon name,
> > and that its presence totally disables any and ALL screen blanker's
> > regardless of whose desktop of the day is installed.  We can
> > incorporate the setting of this, on launching LinuxCNC, and
> > unsetting it when LinuxCNC is being shut down.
> >
> > If you agree that safety overrides paranoia, please consider this as
> > part of the supplied X11 implementations.
> >
> > In the meantime, since xset seems powerless to disable it, can
> > someone tell me how, in xfce4, to disable it. Haveing it kick in in
> > 10 minutes, while the machine is carving a part, and a miss-command
> > does something wrong that needs to be stopped as quickly as
> > possible, having a locked screen requiring a login via a swar

Feature request, but must be universallly accepted by ALL blanker authors

[Gene Heskett]

Greetings x-people;

The LinuxCNC people have just brought it up from Debian wheezy to buster 
for a base install.

But the security paranoia is going to get someone maimed or killed.

Someone has decreed that the screen blanker must be subject to a new 
login before anything can be done about a runaway machine with enough 
horsepower at its disposal to kill.

I have now been 3 days looking for a way to disable this blanker, trying 
several methods by way of xset, only to find 15 minutes later that its 
been undone and the blanker kicks in regardless.

So I am proposing that an env variable be named an agreed upon name, and 
that its presence totally disables any and ALL screen blanker's 
regardless of whose desktop of the day is installed.  We can incorporate 
the setting of this, on launching LinuxCNC, and unsetting it when 
LinuxCNC is being shut down.

If you agree that safety overrides paranoia, please consider this as part 
of the supplied X11 implementations.

In the meantime, since xset seems powerless to disable it, can someone 
tell me how, in xfce4, to disable it. Haveing it kick in in 10 minutes, 
while the machine is carving a part, and a miss-command does something 
wrong that needs to be stopped as quickly as possible, having a locked 
screen requiring a login via a swarf covering equipt keyboard is simply 
dangerous to both the operator and the machine.  So I'm asking how do I 
get rid of it, totally.  We can operate a monitors power switch if we 
are done for the day, but we can't tolerate anything getting in the way 
of controlling that runaway machine with one keystroke during the day.

Please advise.  And thank you.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Xorg.0.log stuck, never stops

[Gene Heskett]

On Sunday 14 June 2020 10:16:47 Adam Nielsen wrote:

> > Because its also a devel machine, haveing 2 SSD's attached where it
> > can build the target sw, there are often 1 minimum to as high as 4
> > ssh -Y logins. But only one in the last several days.
>
> SSH wouldn't do it, but anything that runs on a timer could.  For
> example if you have DPMS power saving to shut off the monitor after a
> few minutes, then when it wakes up again it may query the monitor so
> that it can set the correct screen resolution again.
>
> If you're running a full desktop environment (as opposed to a basic
> install) then there are many things it could be.  If you're running a
> minimal Linux distro with a cut down Xorg install then power saving is
> about the only thing that could be on by default that might do this,
> that I can think of, not counting hardware issues/bad cables which you
> say aren't a problem given the lack of display issues.
>
> > I do not know that to be the case but if a part was
> > being carved at the time, I'd imagine it would be damaged as this
> > nominally 5 milliseconds means the machine is un-monitored for a
> > part wrecking way too long.
>
> This won't stop the system for five milliseconds, it will take five
> milliseconds for the process to complete but other programs will
> continue to run in the background.
>
> However if your lathe control software is that critical with timing,
> then it should be running with its priority set to "realtime" so that
> it takes priority over all other programs anyway.  Otherwise anything
> could hold it up - e.g. random disk cache flushes.
>
> The timestamps are exactly 30 minutes apart down to the second, which
> is a common value for power saving options, so I'd start looking
> there.
>
> Power saving is one thing that can disrupt running processes because
> some devices take enough time to respond to wake up events that the
> system really can be completely blocked for a few milliseconds, so in
> your case where you need code running every millisecond to monitor
> external hardware, I'd be inclined to disable any power saving options
> I could find, including those in the kernel relating to CPU
> throttling, USB devices, etc.
>
> Cheers,
> Adam.

The one thing I found is this in the root crontab
/5 * * * *  date & >>/tmp/mouse-trace; sudo lsusb -vv 2>/dev/null |
grep "Bus 001 Device 006" & >>/tmp/mouse-trace
/5 * * * *  lsusb -v 2&>/dev/null | grep "Bus 001 Device 006" 
>> /tmp/mouse-trace

Which I had added because the mouse was dissapearing.  But thats a 5 
minute interval, which I just expanded to a 30 minute repeat. I'll 
comment it just for S&G.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Xorg.0.log stuck, never stops

[Gene Heskett]

On Sunday 14 June 2020 08:27:04 Adam Nielsen wrote:

> > I just noticed my Xorg.0.log is growing, probably will continue to
> > grow untill the 64GB card is used up, adding this stanza every few
> > minutes:
> >
> > [320458.839] (--) modeset(0): HDMI max TMDS frequency 225000KHz
>
> Do you have anything that might call xrandr or another program at
> regular intervals?  Can't think what else would be continually
> querying the display settings.
>
> Does it still happen if all the monitors are unplugged?  Just to rule
> out any sort of hotplug-related weirdness.
>
> I guess if nothing else you could always add "-logfile /dev/null" to
> the X command line as a last resort.
>
> Cheers,
> Adam.

Because its also a devel machine, haveing 2 SSD's attached where it can 
build the target sw, there are often 1 minimum to as high as 4 ssh -Y 
logins. But only one in the last several days.

None of this is a huge showstopper unless it causes a huge latency to 
occur in the machine control. Normal is for the program if running, to 
take inventory of what the machine is doing and issue corrective actions 
every millisecond. I do not know that to be the case but if a part was 
being carved at the time, I'd imagine it would be damaged as this 
nominally 5 milliseconds means the machine is un-monitored for a part 
wrecking way too long.

I was hoping the time frame between these events might trigger an 
association memory from some of your folks.

[334858.869] (--) modeset(0): HDMI max TMDS frequency 225000KHz
[336658.866] (II) modeset(0): EDID vendor "ONN", prod id 257

That shows the interval between these events as thats the last line of 
the previous event and the first line of another.  And it seems to be 
fairly consistent. Something cron is doing might be one possibility.  It 
is a raspbian buster install as an armhf but could at some point be done 
as a full 64 bit install.  R-pi-4b, 2 G's ram.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Xorg.0.log stuck, never stops

[Gene Heskett]

Greetings all;

Specially built preempt-rt kernel running an 11x56 metal lathe from 
an rpi4b, armhf flavor. Uptodate except for locked kernel.

I just noticed my Xorg.0.log is growing, probably will continue to grow
untill the 64GB card is used up, adding this stanza every few minutes:

[320458.839] (--) modeset(0): HDMI max TMDS frequency 225000KHz
[322258.843] (II) modeset(0): EDID vendor "ONN", prod id 257
[322258.843] (II) modeset(0): Using hsync ranges from config file
[322258.843] (II) modeset(0): Using vrefresh ranges from config file
[322258.843] (II) modeset(0): Printing DDC gathered Modelines:
[322258.843] (II) modeset(0): Modeline "1920x1080"x0.0  148.50  1920 2008 2052 
2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP)
[322258.843] (II) modeset(0): Modeline "1366x768"x0.0   85.50  1366 1436 1579 
1792  768 771 774 798 +hsync +vsync (47.7 kHz e)
[322258.843] (II) modeset(0): Modeline "1920x1080i"x0.0   74.25  1920 2008 2052 
2200  1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e)
[322258.843] (II) modeset(0): Modeline "1280x720"x0.0   74.25  1280 1390 1430 
1650  720 725 730 750 +hsync +vsync (45.0 kHz e)
[322258.844] (II) modeset(0): Modeline "720x480"x0.0   27.00  720 736 798 858  
480 489 495 525 -hsync -vsync (31.5 kHz e)
[322258.844] (II) modeset(0): Modeline "1920x1080"x0.0  148.50  1920 2448 2492 
2640  1080 1084 1089 1125 +hsync +vsync (56.2 kHz e)
[322258.844] (II) modeset(0): Modeline "1440x480"x0.0   54.00  1440 1472 1596 
1716  480 489 495 525 -hsync -vsync (31.5 kHz e)
[322258.844] (II) modeset(0): Modeline "1440x576"x0.0   54.00  1440 1464 1592 
1728  576 581 586 625 -hsync -vsync (31.2 kHz e)
[322258.844] (II) modeset(0): Modeline "640x480"x0.0   25.18  640 656 752 800  
480 490 492 525 -hsync -vsync (31.5 kHz e)
[322258.844] (II) modeset(0): Modeline "720x576"x0.0   27.00  720 732 796 864  
576 581 586 625 -hsync -vsync (31.2 kHz e)
[322258.844] (II) modeset(0): Modeline "1280x720"x0.0   74.25  1280 1720 1760 
1980  720 725 730 750 +hsync +vsync (37.5 kHz e)
[322258.844] (II) modeset(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  
600 601 605 628 +hsync +vsync (37.9 kHz e)
[322258.844] (II) modeset(0): Modeline "800x600"x0.0   36.00  800 824 896 1024  
600 601 603 625 +hsync +vsync (35.2 kHz e)
[322258.844] (II) modeset(0): Modeline "640x480"x0.0   31.50  640 656 720 840  
480 481 484 500 -hsync -vsync (37.5 kHz e)
[322258.844] (II) modeset(0): Modeline "640x480"x0.0   31.50  640 664 704 832  
480 489 492 520 -hsync -vsync (37.9 kHz e)
[322258.844] (II) modeset(0): Modeline "640x480"x0.0   30.24  640 704 768 864  
480 483 486 525 -hsync -vsync (35.0 kHz e)
[322258.845] (II) modeset(0): Modeline "720x400"x0.0   28.32  720 738 846 900  
400 412 414 449 -hsync +vsync (31.5 kHz e)
[322258.845] (II) modeset(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 
1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[322258.845] (II) modeset(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 
1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[322258.845] (II) modeset(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184 
1328  768 771 777 806 -hsync -vsync (56.5 kHz e)
[322258.845] (II) modeset(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 
1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[322258.845] (II) modeset(0): Modeline "832x624"x0.0   57.28  832 864 928 1152  
624 625 628 667 -hsync -vsync (49.7 kHz e)
[322258.845] (II) modeset(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  
600 601 604 625 +hsync +vsync (46.9 kHz e)
[322258.845] (II) modeset(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  
600 637 643 666 +hsync +vsync (48.1 kHz e)
[322258.845] (II) modeset(0): Modeline "1680x1050"x0.0  119.00  1680 1728 1760 
1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz e)
[322258.845] (II) modeset(0): Modeline "1440x900"x0.0   88.75  1440 1488 1520 
1600  900 903 909 926 +hsync -vsync (55.5 kHz e)
[322258.846] (II) modeset(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 
1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[322258.846] (II) modeset(0): Modeline "1280x960"x0.0  108.00  1280 1376 1488 
1800  960 961 964 1000 +hsync +vsync (60.0 kHz e)
[322258.846] (II) modeset(0): Modeline "1680x1050"x0.0  187.00  1680 1800 1976 
2272  1050 1053 1059 1099 -hsync +vsync (82.3 kHz e)
[322258.847] (--) modeset(0): HDMI max TMDS frequency 225000KHz

Video looks great. Any idea what the problem might be?

Thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X not starting on a 4GB rock64

[Gene Heskett]

On Thursday 26 April 2018 08:57:48 Gene Heskett wrote:

> On Thursday 26 April 2018 02:58:55 Michal Srb wrote:
> > It looks to me like if both armsoc and modesetting are trying to use
> > the same GPU, acting like there are two separate GPUs.
>
> There are supposedly 2 gpu's in this chipset. Mali 400's ack the log.
>
> > The modesetting
> > fails to call drmSetMaster on it, maybe because armsoc already did
> > that first.
>
> In /etc/X11/xorg.conf.d/ there are 3 files
> 20-armsoc.conf:
> Section "Device"
> Identifier  "Mali FBDEV"
> Driver  "armsoc"
> Option  "fbdev" "/dev/fb0"
> Option  "Fimg2DExa" "false"
> Option  "DRI2"  "true"
> Option  "DRI2_PAGE_FLIP""false"
> Option  "DRI2_WAIT_VSYNC"   "true"
> Option  "CursorPlaneType"   "2"
> EndSection
>
> Section "Screen"
> Identifier  "DefaultScreen"
> Device  "Mali FBDEV"
> DefaultDepth24
> EndSection
>
> And
> 20-modesetting.conf:
> Section "Device"
> Identifier  "Rockchip Graphics"
> Driver  "modesetting"
> Option  "AccelMethod""glamor"
> Option  "Dri2Vsync"  "false"
> EndSection
> And a .bak copy of the above.
>
> > You could try if it gets better by disabling additonal GPUs by
> > adding a configuration file like this (or appending it to your
> > /etc/X11/xorg.conf file if you have):
> >
> > /etc/X11/xorg.conf.d/80-serverflags.conf:
> >
> > Section "ServerFlags"
> >   Option "AutoAddGPU" "False"
> > EndSection
>
> I'm doing all this from an ssh login, and for some (security I assume)
> reason there are pauses in the boot that need the return key pressed.
> And until it has tried to start x, there is no network. Security
> concerns are starting to be a PITA. Thus is a well isolated home
> network, dd-wrt in the router is my guard dog and has very sharp
> teeth.
>
> Its in the garage (my 2nd mancave) and I'll have to dress and go out
> to reboot it. Early, and I need to feed the missus first, she's stuck
> in a recliner with a broken leg. Paper mache for bones at 78, and I'm
> 83. Retired tv bcast engineer.
>
> Mali is mentioned in the kern.log. let me see if I can find that and
> paste it: root@rock64:/etc/X11/xorg.conf.d# grep -B15 Mali
> /var/log/kern.log Apr 24 15:47:47 rock64 kernel: [3.526913] I :
> [File] : drivers/gpu/arm/mali400/mali/linux/mali_kernel_linux.c;
> [Line] : 415; [Func] : mali_module_init(); svn_rev_string_from_arm of
> this mali_ko is '-ac51b70a', rk_ko_ver is '5', built at '12:21:25', on
> 'Apr 22 2018'. Apr 24 15:47:47 rock64 kernel: [3.535712]
> mali-utgard ff30.gpu: mali_platform_device->num_resources = 9 Apr
> 24 15:47:47 rock64 kernel: [3.539788] mali-utgard ff30.gpu:
> resource[0].start = 0x0xff30 Apr 24 15:47:47 rock64
> kernel: [3.543873] mali-utgard ff30.gpu: resource[1].start =
> 0x0xff30 Apr 24 15:47:47 rock64 kernel: [3.547921]
> mali-utgard ff30.gpu: resource[2].start = 0x0x0012 Apr
> 24 15:47:47 rock64 kernel: [3.551901] mali-utgard ff30.gpu:
> resource[3].start = 0x0x0013 Apr 24 15:47:47 rock64
> kernel: [3.555848] mali-utgard ff30.gpu: resource[4].start =
> 0x0x0014 Apr 24 15:47:47 rock64 kernel: [3.559783]
> mali-utgard ff30.gpu: resource[5].start = 0x0x0015 Apr
> 24 15:47:47 rock64 kernel: [3.563709] mali-utgard ff30.gpu:
> resource[6].start = 0x0x0016 Apr 24 15:47:47 rock64
> kernel: [3.567607] mali-utgard ff30.gpu: resource[7].start =
> 0x0x0017 Apr 24 15:47:47 rock64 kernel: [3.571429]
> mali-utgard ff30.gpu: resource[8].start = 0x0x0018 Apr
> 24 15:47:47 rock64 kernel: [3.575205] D : [File] :
> drivers/gpu/arm/mali400/mali/platform/rk/rk.c; [Line] : 617; [Func] :
> mali_platform_device_init(); to add platform_specific_data to
> platform_device_of_mali. Apr 24 15:47:47 rock64 kernel: [3.583509]
> mali-utgard ff30.gpu: gpu_leakage=12 Apr 24 15:47:47 rock64
> kernel: [3.587421] mali-utgard ff30.gpu:
> gpu_leakage-volt-sel=1 Apr 24 15:47:47 rock64 kernel: [3.591424]
> mali-utgard ff3

Re: X not starting on a 4GB rock64

[Gene Heskett]

On Thursday 26 April 2018 02:58:55 Michal Srb wrote:

> It looks to me like if both armsoc and modesetting are trying to use
> the same GPU, acting like there are two separate GPUs. 

There are supposedly 2 gpu's in this chipset. Mali 400's ack the log. 

> The modesetting 
> fails to call drmSetMaster on it, maybe because armsoc already did
> that first.

In /etc/X11/xorg.conf.d/ there are 3 files
20-armsoc.conf:
Section "Device"
Identifier  "Mali FBDEV"
Driver  "armsoc"
Option  "fbdev" "/dev/fb0"
Option  "Fimg2DExa" "false"
Option  "DRI2"  "true"
Option  "DRI2_PAGE_FLIP""false"
Option  "DRI2_WAIT_VSYNC"   "true"
Option  "CursorPlaneType"   "2"
EndSection

Section "Screen"
Identifier  "DefaultScreen"
Device  "Mali FBDEV"
DefaultDepth24
EndSection

And
20-modesetting.conf:
Section "Device"
Identifier  "Rockchip Graphics"
Driver  "modesetting"
Option  "AccelMethod""glamor"
Option  "Dri2Vsync"  "false"
EndSection
And a .bak copy of the above.

> You could try if it gets better by disabling additonal GPUs by adding
> a configuration file like this (or appending it to your
> /etc/X11/xorg.conf file if you have):

> /etc/X11/xorg.conf.d/80-serverflags.conf:
>
> Section "ServerFlags"
>   Option "AutoAddGPU" "False"
> EndSection
>
I'm doing all this from an ssh login, and for some (security I assume) 
reason there are pauses in the boot that need the return key pressed.
And until it has tried to start x, there is no network. Security concerns
are starting to be a PITA. Thus is a well isolated home network, dd-wrt
in the router is my guard dog and has very sharp teeth.

Its in the garage (my 2nd mancave) and I'll have to dress and go out
to reboot it. Early, and I need to feed the missus first, she's stuck
in a recliner with a broken leg. Paper mache for bones at 78, and I'm 83.
Retired tv bcast engineer.

Mali is mentioned in the kern.log. let me see if I can find that and paste it:
root@rock64:/etc/X11/xorg.conf.d# grep -B15 Mali /var/log/kern.log
Apr 24 15:47:47 rock64 kernel: [3.526913] I : [File] : 
drivers/gpu/arm/mali400/mali/linux/mali_kernel_linux.c; [Line] : 415; [Func] : 
mali_module_init(); svn_rev_string_from_arm of this mali_ko is '-ac51b70a', 
rk_ko_ver is '5', built at '12:21:25', on 'Apr 22 2018'.
Apr 24 15:47:47 rock64 kernel: [3.535712] mali-utgard ff30.gpu: 
mali_platform_device->num_resources = 9
Apr 24 15:47:47 rock64 kernel: [3.539788] mali-utgard ff30.gpu: 
resource[0].start = 0x0xff30
Apr 24 15:47:47 rock64 kernel: [3.543873] mali-utgard ff30.gpu: 
resource[1].start = 0x0xff30
Apr 24 15:47:47 rock64 kernel: [3.547921] mali-utgard ff30.gpu: 
resource[2].start = 0x0x0012
Apr 24 15:47:47 rock64 kernel: [3.551901] mali-utgard ff30.gpu: 
resource[3].start = 0x0x0013
Apr 24 15:47:47 rock64 kernel: [3.555848] mali-utgard ff30.gpu: 
resource[4].start = 0x0x0014
Apr 24 15:47:47 rock64 kernel: [3.559783] mali-utgard ff30.gpu: 
resource[5].start = 0x0x0015
Apr 24 15:47:47 rock64 kernel: [3.563709] mali-utgard ff30.gpu: 
resource[6].start = 0x0x0016
Apr 24 15:47:47 rock64 kernel: [3.567607] mali-utgard ff30.gpu: 
resource[7].start = 0x0x0017
Apr 24 15:47:47 rock64 kernel: [3.571429] mali-utgard ff30.gpu: 
resource[8].start = 0x0x0018
Apr 24 15:47:47 rock64 kernel: [3.575205] D : [File] : 
drivers/gpu/arm/mali400/mali/platform/rk/rk.c; [Line] : 617; [Func] : 
mali_platform_device_init(); to add platform_specific_data to 
platform_device_of_mali.
Apr 24 15:47:47 rock64 kernel: [3.583509] mali-utgard ff30.gpu: 
gpu_leakage=12
Apr 24 15:47:47 rock64 kernel: [3.587421] mali-utgard ff30.gpu: 
gpu_leakage-volt-sel=1
Apr 24 15:47:47 rock64 kernel: [3.591424] mali-utgard ff30.gpu: Looking 
up mali-supply from device tree
Apr 24 15:47:47 rock64 kernel: [3.593383] Mali: Mali device driver loaded

>
> Michal Srb

Thank you Michal, results in a later post after its been rebooted. I
should have included this stuff in the first post.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

X not starting on a 4GB rock64

[Gene Heskett]

740] (II) modeset(G0): Monitor name: K202HQL
[   331.740] (II) modeset(G0): Serial No: T0CAA0088512
[   331.740] (II) modeset(G0): EDID (in hex):
[   331.740] (II) modeset(G0):  00000472e003dce14061
[   331.740] (II) modeset(G0):  0e1a0103802b1878ca94a5a1a027
[   331.740] (II) modeset(G0):  0f5054bfef8081c08100714f81408180
[   331.740] (II) modeset(G0):  010101010101662156aa51001e30468f
[   331.740] (II) modeset(G0):  3300b2ec101e00fd00384c1f
[   331.740] (II) modeset(G0):  530e000a20202020202000fc004b
[   331.740] (II) modeset(G0):  32303248514c0a202020202000ff
[   331.740] (II) modeset(G0):  005430434141303038383531320a00bf
[   331.741] (II) modeset(G0): Printing probed modes for output HDMI-1-1
[   331.741] (II) modeset(G0): Modeline "1366x768"x59.8   85.50  1366 1436 1579 
1792  768 771 774 798 +hsync +vsync (47.7 kHz eP)
[   331.741] (II) modeset(G0): Modeline "1280x1024"x75.0  135.00  1280 1296 
1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[   331.741] (II) modeset(G0): Modeline "1280x1024"x60.0  108.00  1280 1328 
1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[   331.741] (II) modeset(G0): Modeline "1280x960"x60.0  108.00  1280 1376 1488 
1800  960 961 964 1000 +hsync +vsync (60.0 kHz e)
[   331.741] (II) modeset(G0): Modeline "1280x800"x59.9   71.00  1280 1328 1360 
1440  800 803 809 823 +hsync -vsync (49.3 kHz e)
[   331.741] (II) modeset(G0): Modeline "1152x864"x75.0  108.00  1152 1216 1344 
1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
[   331.741] (II) modeset(G0): Modeline "1280x720"x60.0   74.25  1280 1390 1430 
1650  720 725 730 750 +hsync +vsync (45.0 kHz e)
[   331.741] (II) modeset(G0): Modeline "1024x768"x75.0   78.75  1024 1040 1136 
1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[   331.741] (II) modeset(G0): Modeline "1024x768"x70.1   75.00  1024 1048 1184 
1328  768 771 777 806 -hsync -vsync (56.5 kHz e)
[   331.741] (II) modeset(G0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 
1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[   331.741] (II) modeset(G0): Modeline "800x600"x72.2   50.00  800 856 976 
1040  600 637 643 666 +hsync +vsync (48.1 kHz e)
[   331.741] (II) modeset(G0): Modeline "800x600"x75.0   49.50  800 816 896 
1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
[   331.741] (II) modeset(G0): Modeline "800x600"x60.3   40.00  800 840 968 
1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[   331.741] (II) modeset(G0): Modeline "800x600"x56.2   36.00  800 824 896 
1024  600 601 603 625 +hsync +vsync (35.2 kHz e)
[   331.741] (II) modeset(G0): Modeline "640x480"x75.0   31.50  640 656 720 840 
 480 481 484 500 -hsync -vsync (37.5 kHz e)
[   331.741] (II) modeset(G0): Modeline "640x480"x72.8   31.50  640 664 704 832 
 480 489 492 520 -hsync -vsync (37.9 kHz e)
[   331.741] (II) modeset(G0): Modeline "640x480"x59.9   25.18  640 656 752 800 
 480 490 492 525 -hsync -vsync (31.5 kHz e)
[   331.741] (==) modeset(G0): Using gamma correction (1.0, 1.0, 1.0)
[   331.741] (**) modeset(G0): Display dimensions: (430, 240) mm
[   331.741] (**) modeset(G0): DPI set to (60, 81)
[   331.741] (II) Loading sub module "fb"
[   331.741] (II) LoadModule: "fb"
[   331.742] (II) Loading /usr/lib/xorg/modules/libfb.so
[   331.742] (II) Module fb: vendor="X.Org Foundation"
[   331.742]compiled for 1.19.2, module version = 1.0.0
[   331.742]ABI class: X.Org ANSI C Emulation, version 0.4
[   331.742] (--) Depth 24 pixmap format is 32 bpp
[   331.742] (EE) modeset(G0): drmSetMaster failed: Invalid argument
[   331.742] (EE) 
Fatal server error:
[   331.742] (EE) AddScreen/ScreenInit failed for gpu driver 0 -1
[   331.742] (EE) 
[   331.742] (EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
[   331.742] (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
additional information.
[   331.742] (EE) 
[   331.768] (EE) Server terminated with error (1). Closing log file.

This card draws its updates from debian-arm, and ayufan's git account 
for the rock64.

Many thanks.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: arm64 aka rock64, x fails on stretch

[Gene Heskett]

On Tuesday 24 April 2018 22:24:06 Alan Corey wrote:

> Don't know anything about that but on a Pi at least configuration
> files that get replaced in upgrades end up in ~/oldconffiles
>
> And I just got Valgrind working on a pi by building from source, never
> seen it work before.  Source later than about June 2017 handles Linux
> ARM better.  http://www.valgrind.org
>
> Do you have a video driver to suit your video output that X gets along
> with?  If you have a VNC server on there, is that normal?  That sort
> of does a mockup of X on a screen, but has its own drivers.

This kernel claims to have the mali video support in it.
>
> And try apropos drm about the first error.  That's Direct Rendering
> Manager.  Also there's an error drmSetMaster failed: Invalid argument
> that's related.  Seems like you should have a VESA driver or something
> as a backup.  I think a different kernel config might knock that out.
> I had a devil of a time with my hp which is nvidia.
>
> On 4/24/18, Gene Heskett  wrote:
> > But its ayufan's latest kernel,
> >
> > It makes it, after pressing enter, to a black screen with a blinking
> > underline curser, but doesn't start x. Both task xfce4 and just now,
> > LDXE have been installed.

And I have since come to the conclusion that it never changes to vt7. If, 
at the point it reaches the black screen, first with a few odd blinks to 
the cursor, which eventually settles into a 1 second steady blink, but I 
then do something like plugging in a usb thing, the logging is spit out 
on this screen. This includes the buttons for the wireless keyboard and 
wireless mouse. But the keyboard/mouse aren't able to elicit any 
response from the system.

At this point, I'm going to take the Xorg.0.log to the Xorg mailing list 
for their perusal.

To the xorg list, this is a rockchip rock64, with 4GB of dram, and x is 
not starting at boot time. Onboard Mali gfx just now being brought to 
life, its been running on an fb till now.

> > The Xorg.0.log says no screens found. Monitor's native is 1366x768,
> > and at one point a week back it was running, poorly, fuzzy etc at
> > 1200xsomething.
> >
From the most recent reboot after installing LXDE, Xorg.0.log is 
attached.

But still trying to bring up xfce4.

Please see the attached log, and tell me what I need next.

And thank you.
-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
[   330.899] 
X.Org X Server 1.19.2
Release Date: 2017-03-02
[   330.899] X Protocol Version 11, Revision 0
[   330.899] Build Operating System: Linux 4.9.0-4-arm64 aarch64 Debian
[   330.899] Current Operating System: Linux rock64 4.4.120-rockchip-ayufan-210 #1 SMP Sun Apr 22 12:25:01 UTC 2018 aarch64
[   330.899] Kernel command line: rw root=LABEL=linux-root rootwait rootfstype=ext4 panic=10 init=/sbin/init coherent_pool=1M ethaddr=3e:1b:98:17:e3:8c eth1addr=3e:1b:98:17:e3:ac serial=cdad738cabd5366 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1
[   330.899] Build Date: 16 October 2017  08:11:43AM
[   330.899] xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support) 
[   330.899] Current version of pixman: 0.34.0
[   330.899] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[   330.899] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   330.899] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Apr 25 00:04:28 2018
[   330.900] (==) Using config directory: "/etc/X11/xorg.conf.d"
[   330.900] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   330.900] (==) No Layout section.  Using the first Screen section.
[   330.900] (**) |-->Screen "DefaultScreen" (0)
[   330.900] (**) |   |-->Monitor ""
[   330.901] (**) |   |-->Device "Mali FBDEV"
[   330.901] (**) |   |-->GPUDevice "Rockchip Graphics"
[   330.901] (==) No monitor specified for screen "DefaultScreen".
	Using a default monitor configuration.
[   330.901] (==) Automatically adding devices
[   330.901] (==) Automatically enabling devices
[   330.901] (==) Automatically adding GPU devices
[   330.901] (==) Max clients allowed: 256, resource mask: 0x1f
[   330.901] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   330.901] 	Entry deleted from font path.
[   330.901] (==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	

Re: opengl and drm on a pi 3b?

[Gene Heskett]

On Thursday 16 March 2017 14:18:53 you wrote:

> Hi
>
> As this isn't an "X" answer I've skipped the list.

And I've put it back so its in the archive FFR.

> What application 
> are you using?  Do you actually need X? do you actually need OpenGL?
>
Yes on both counts. The app, linuxcnc, has a nice gui control interface 
which includes a backplot of the machines motions while its carving up a 
block of metal to make something.  Screen refresh rate with what I am 
getting is about 15 frames a second, just noticeably slow. The numbers 
in the digital readout of the cutter location in 3d space, should just 
roll by, but they jump a decade or more in displayed value if the 
machine is moving at 5 inches a minute now.

> I ask these questions 'cos as it stands X + GL + HW Video is still a
> bit unsupported on the Pi.  If you just want video then junk X & OGL
> and your life will be a lot better.  X + HW decode can be made to work
> just about acceptably but it takes some effort, add OGL into the mix
> and whilst it should make life better by and large it doesn't (yet) as
> the mmal stacks don't play nice with the GL stacks.

Is there even movement afoot to fix this? If its fixed, the pi 3b can 
easily take over from the power hungry x86 boxes we generally use as the 
driving iron. Not an overnight takeover, but as the x86 boxes age out 
and people are becoming more conscious of the energy bills, it will 
happen.
>
> Regards
>
> JC
Thanks John.
>
> >Hello all, been a while since I rang your doorbell, greetings from
> > West Virginia;
> >
> >I am in the process of converting an old lathe to cnc, and using a pi
> > 3b as the driver.
> >
> >Doing some work on the configuration today, I got curious to see if
> > the features I was adding to the configuration were pushing the poor
> > pi to the point of exhaustion. Firing up htop, the various bits and
> > pieces that together make up linuxcnc, were a total of about 4 or 5%
> > of the cpu load.  Compton, the x compositor, was burning something
> > in the region of 165%, or a little over 1.5 of its 4 cores. It was
> > also a few megabytes into swap, so I rebooted it, after which
> > compton was only using perhaps 35% of one core.
> >
> >But my main reason for posting is to see if any progress is being
> > made on opengl and drm drivers for that bcm video the pi has.  The
> > display is just slow enough to be noticeable.  The machine its
> > driving can move at up to about 100 inches a minute, with bone
> > breaking force, so it would be a definite safety advantage if the
> > video could keep up with the machine in something resembling real
> > time.
> >
> >So what, if any, is the status of faster video drivers for the pi's
> > that use the bcm video?
> >
> >Thanks all.
> >
> >Cheers, Gene Heskett


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: opengl and drm on a pi 3b?

[Gene Heskett]

On Thursday 16 March 2017 13:55:44 Eric Anholt wrote:

> Gene Heskett  writes:
> > Hello all, been a while since I rang your doorbell, greetings from
> > West Virginia;
> >
> > I am in the process of converting an old lathe to cnc, and using a
> > pi 3b as the driver.
> >
> > Doing some work on the configuration today, I got curious to see if
> > the features I was adding to the configuration were pushing the poor
> > pi to the point of exhaustion. Firing up htop, the various bits and
> > pieces that together make up linuxcnc, were a total of about 4 or 5%
> > of the cpu load.  Compton, the x compositor, was burning something
> > in the region of 165%, or a little over 1.5 of its 4 cores. It was
> > also a few megabytes into swap, so I rebooted it, after which
> > compton was only using perhaps 35% of one core.
>
> That sounds like you're running your compositor in software rendering.

According to the Xorg.0.log, yes. But I've no idea how to fix that.

Thanks Eric.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

opengl and drm on a pi 3b?

[Gene Heskett]

Hello all, been a while since I rang your doorbell, greetings from West 
Virginia;

I am in the process of converting an old lathe to cnc, and using a pi 3b 
as the driver.

Doing some work on the configuration today, I got curious to see if the 
features I was adding to the configuration were pushing the poor pi to 
the point of exhaustion. Firing up htop, the various bits and pieces 
that together make up linuxcnc, were a total of about 4 or 5% of the cpu 
load.  Compton, the x compositor, was burning something in the region of 
165%, or a little over 1.5 of its 4 cores. It was also a few megabytes 
into swap, so I rebooted it, after which compton was only using perhaps 
35% of one core.

But my main reason for posting is to see if any progress is being made on 
opengl and drm drivers for that bcm video the pi has.  The display is 
just slow enough to be noticeable.  The machine its driving can move at 
up to about 100 inches a minute, with bone breaking force, so it would 
be a definite safety advantage if the video could keep up with the 
machine in something resembling real time.

So what, if any, is the status of faster video drivers for the pi's that 
use the bcm video?

Thanks all.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Bringing up a raspi in a machine shop environment.

[Gene Heskett]

Greetings folks;

From the current Xorg.0.log:
===
[10.932] (II) AIGLX: Screen 0 is not DRI2 capable
[10.932] (EE) AIGLX: reverting to software rendering
[11.824] (II) AIGLX: Loaded and initialized swrast
[11.824] (II) GLX: Initialized DRISWRAST GL provider for screen 0
===
Is this normal on a raspi-3b, or do I need to install a better driver?

And:

[12.144] (II) config/udev: Adding input device MOSART Semi. 2.4G RF 
Keyboard & Mouse (/dev/input/event1)
[12.144] (**) MOSART Semi. 2.4G RF Keyboard & Mouse: Applying 
InputClass "evdev pointer catchall"
[12.144] (**) MOSART Semi. 2.4G RF Keyboard & Mouse: Applying 
InputClass "evdev keyboard catchall"
[12.144] (II) Using input driver 'evdev' for 'MOSART Semi. 2.4G RF 
Keyboard & Mouse'
[12.144] (**) MOSART Semi. 2.4G RF Keyboard & Mouse: always reports 
core events
[12.144] (**) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: 
Device: "/dev/input/event1"
[12.144] (--) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: Vendor 
0x3938 Product 0x1032
[12.145] (--) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: Found 9 
mouse buttons
[12.145] (--) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: Found 
scroll wheel(s)
[12.145] (--) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: Found 
relative axes
[12.145] (--) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: Found x 
and y relative axes
[12.145] (--) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: Found 
absolute axes
[12.145] (II) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: Forcing 
absolute x/y axes to exist.
[12.145] (--) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: Found 
keys
[12.145] (II) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: 
Configuring as mouse
[12.145] (II) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: 
Configuring as keyboard
[12.145] (II) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: Adding 
scrollwheel support
[12.145] (**) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: 
YAxisMapping: buttons 4 and 5
[12.145] (**) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: 
EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[12.145] (**) 
Option "config_info" 
"udev:/sys/devices/platform/soc/3f98.usb/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1:1.1/0003:3938:1032.0002/input/input1/event1"
[12.145] (II) XINPUT: Adding extended input device "MOSART Semi. 2.4G 
RF Keyboard & Mouse" (type: KEYBOARD, id 7)
[12.145] (**) Option "xkb_rules" "evdev"
[12.145] (**) Option "xkb_model" "pc105"
[12.145] (**) Option "xkb_layout" "gb"
[12.146] (II) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: 
initialized for relative axes.
[12.146] (WW) evdev: MOSART Semi. 2.4G RF Keyboard & Mouse: ignoring 
absolute axes.
[12.146] (**) MOSART Semi. 2.4G RF Keyboard & Mouse: (accel) keeping 
acceleration scheme 1
[12.146] (**) MOSART Semi. 2.4G RF Keyboard & Mouse: (accel) 
acceleration profile 0
[12.146] (**) MOSART Semi. 2.4G RF Keyboard & Mouse: (accel) 
acceleration factor: 2.000
[12.147] (**) MOSART Semi. 2.4G RF Keyboard & Mouse: (accel) 
acceleration threshold: 4
[12.148] (II) config/udev: Adding input device MOSART Semi. 2.4G RF 
Keyboard & Mouse (/dev/input/mouse0)
[12.148] (II) No input driver specified, ignoring this device.
[12.148] (II) This device may have been added with another device 
file.
===
this is I believe, a touchpad and is part of the cheap keyboard, and 
located where ones right little finger often touches it as I'm typing 
and causes tons of miss-fires, focus stealing and other hate and 
discontent.  Can this PITA be disabled/ignored? It seems to be slow for 
a mouse, but very sensitive to a touch, so I am not convinced that a 
sheet of lexan glued above it would disable the touch functions.

There is also a std wireless mouse plugged in which works much better, 
and is I believe being reported as event2 further down in this log.

Thank you.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: raspian, jessie full install on a raspi 3b, mouse in heavy syrup.

[Gene Heskett]

On Wednesday 30 November 2016 06:38:36 Eric Gunther wrote:

> On Wed, 2016-11-30 at 00:52 -0500, Gene Heskett wrote:
> > Greetings all;
> >
> > I've no clue if any of you are familar with raspian, built for the
> > armhf
> > SBC's..
> >
> > I just installed it, and I am pleasantly surprised, it does almost
> > everything well, except:
> >
> > When the mouse is moved, there is a huge lag, taking a fat second to
> > move
> > the pointer to the new location, like there is a low pass filter in
> > the
> > data path between the mouses data coming into the usb port, and
> > where its fed into X. There is a tuning utility for kbd and rodent,
> > and it does seem to have some slight effect on how it moves but the
> > extremes of
> > the two sliders have no effect on this moving in cold molasses
> > motion.
> > Its very distracting, taking around 4 to 6 seconds to do something
> > with
> > the mouse, that I can do in a second or less on a Dell 6 feet away
> > running a milling machine.
> >
> > Clues checked, url's read etc.
> >
> > Thanks all.
> >
> > Cheers, Gene Heskett
>
> I think you need to edit cmdline.txt.  I believe its in the boot
> directory.  It will look like this:
>
> dwc_otg.lpm_enable=0
> console=ttyAMA0,115200
> kgdboc=ttyAMA0,115200
> console=tty1
> root=/dev/mmcblk0p2
> rootfstype=ext4
> elevator=deadline
> rootwait
> Some common options:
>
> dwc_otg.speed=1
> USB v1 speed
> smsc95xx.turbo_mode=N
> if the raspberrypi freezes after filling the log withe kevent dropped.
> smsc95xx.macaddr=B8:27:EB:59:EB:25
> it will override the default mac adress with the specified one.
> dwc_otg.microframe_schedule=1
> console=ttyAMA0,115200
> usbhid.mousepoll=8
> ip=192.168.0.10
>
>
> Play with the usbhid.mousepoll=8 options.
>
> references:
>
> http://elinux.org/RPi_cmdline.txt
>
> https://github.com/raspberrypi/linux/issues/642
>
>
> -eg
>
That "usbhid.mousepoll=0" was not in that file, so I appended it, but 
will not reboot until I am at the machine to observe.  Thank you very 
much.

I also see that apt is upgrading 9 packages, including the raspberry 
kernel.  So I will check when its done to see if that option survived.

And at the 54% mark of the unpack and install, it has crashed, or 
disconnected my ssh login.  No, it was installing kernel headers, which 
apparently took several minutes but is now progressing again. And that 
setting survived the update from kernel 4.4.27 v7 to 4.4.34 v7. Reboot 
in progress, uname now shows 

4.4.34-v7+ #930 SMP Wed Nov 23 15:20:41 GMT 2016 armv7l GNU/Linux

Looks promising. Mouse is fixed.

Now I wish for more workspaces. 1 more would be a great help. I am 
spoiled with 10 setup on this old relic phenom. :)

Thanks Eric.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

raspian, jessie full install on a raspi 3b, mouse in heavy syrup.

[Gene Heskett]

Greetings all;

I've no clue if any of you are familar with raspian, built for the armhf 
SBC's..

I just installed it, and I am pleasantly surprised, it does almost 
everything well, except:

When the mouse is moved, there is a huge lag, taking a fat second to move 
the pointer to the new location, like there is a low pass filter in the 
data path between the mouses data coming into the usb port, and where 
its fed into X. There is a tuning utility for kbd and rodent, and it 
does seem to have some slight effect on how it moves but the extremes of 
the two sliders have no effect on this moving in cold molasses motion.  
Its very distracting, taking around 4 to 6 seconds to do something with 
the mouse, that I can do in a second or less on a Dell 6 feet away 
running a milling machine.

Clues checked, url's read etc.

Thanks all.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

On Tuesday 29 November 2016 03:39:51 Thomas Lübking wrote:

> On Mon, Nov 28, 2016 at 11:59:26PM -0500, Gene Heskett wrote:
> >root   797  0.0  1.9 271380 33600 tty7 Ssl+ 20:50
> >0:02 /usr/lib/xorg/Xorg -core :0 -seat
> >seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
> >
> >gene  4114  0.0  0.0   5564   908 pts/8S+   23:48   0:00
> >grep --color=auto listen
> >
> >builders took advantage of that to get rid of 100k of object code. 
> > So I have challenged the odroid people to actually make it work.
>
> Got any clue on this or just a hunch? There's an explicit nolisten
> switch that didn't end up there magically but will oc. prevent tcp
> access for sure.
>
> >That server starts automatically.
>
> That's the "problem" - ask the odroid people about "automatically"
> (i've no experience with that system, sorry)
>
> >The line that starts it, xinit/xsessionrc specifically says -listen
> > tcp as an argument for /usr/bin/X
>
> I doubt the call is simply altered from listen to nolisten.
> Pass it some unexpected bullshit argument ("-gnarf") and see whether
> that has some impact - otherwise i'd say whatever starts X in that
> environment doesn't care about xinit/xsessionrc at all.
>
> Cheers,
> Thomas

Well, the droid may have a place sometime in the future, but at the 
moment it has been such a pain in my rear that it was popped of the 
panel, disconnected from the psu, and tossed on a high shelf.

I had been instructed to originally install the jessie-lite version of 
raspian, but I went back to the site and pulled the full install image, 
and wrote that to the u-sd card. sync'd it, then unplugged it and 
plugged it back in and the automount dutifully mad it available 
as /media/usb1 and /media/usb2.

So I dived into the /etc directory and installed my network setup, and 
made myself user 1000:1000, changing the name pi to gene anyplace I 
found it, making me the first user like I shoulda been in the first.

And of course I forgot to make the network stuff immutable, so N-M 
destroyed it, as usual. A couple root sessions with nano, followed by 
some chattr +i on resolv.conf and interfaces fixed all that up. I'll 
have to see if I can remove that POS, but at least it can't cripple me 
again.

This boots to a gui they call PIXEL, fair, needs some colors adjusted.

I upgraded it to the latest, then installed synaptic since I couldn't 
make out which end of the horse their package manager was faceing me.

I had saved the ~/linuxcnc directory out, and wrote it back to my new 
$home directory, and I installed the bleeding edge linuxcnc.

modprobed the spi stuff into memory, fired up linuxcnc, and the interface 
card responded properly to the spi from linuxcnc, reporting a full list 
of its capabilities. So I loaded up a program to carve a chess pawn, 
homed it and hit the r key.  And was blown away, it was running at about 
a 20 frame/second display rate! With nothing plugged into the droid, the 
raspi 3b was doing it all. No worries about whether or not x was 
listening on a tcp port (its not according to htop).  Put the modprobed 
stuff into the load list file in /etc/modules. Rebooted, and it still 
Just Works(TM).

I am indeed pleased. I might even sleep well tonight.  Now to get the 
rest of it built & wired up.

And in about 30 minutes amanda will see if it can back that puppy up. The 
checker didn't fuss, so I believe that will work.

Only one problem, which I'll pose as a separate post.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

On Tuesday 29 November 2016 13:48:07 Antoine Martin wrote:

> On 29/11/16 18:52, Gene Heskett wrote:
> > On Tuesday 29 November 2016 04:18:09 Antoine Martin wrote:
> >>>>>> If you exclude the 4k fullscreen video use case - which is a
> >>>>>> worst case scenario for remote display (there are tricks to
> >>>>>> deal with that too if you are willing to make sacrifices), then
> >>>>>> screen updates are actually much more manageable, even on a
> >>>>>> 1Gbps shared link.
> >>>>>
> >>>>> nope. not really. do the math. buy a few arm dev boards. :) find
> >>>>> out that you won't get 1gigabit. even 100mbit is pushing things.
> >>>>
> >>>> Even 100mbit is perfectly usable for remote access provided you
> >>>> use the right tools and make some sacrifices. FYI: 4K@60 "fits"
> >>>> in H264 ~60Mbps. But again, as I said above, just don't expect to
> >>>> handle fullscreen video on arm where *we* don't support hardware
> >>>> H264 decoding. (though other tools might)
> >>>
> >>> but we're not talking video streams. we're talking x11.
> >>
> >> I believe the OP's requirement is to run an X11 application on one
> >> system and display it on the arm system, at a better framerate than
> >> is being offered currently by X11-over-ssh.
> >
> > Slight correction, the application that is generating the image
> > data, is running on the pi 3b, the system doing the viewing and
> > control, is to run on the odroid-c2, which does have the gfx
> > horsepower and memory to do it.
>
> Oh, OK. Then you may want to look into VirtualGL.
>
> Cheers
> Antoine

OP here. I am in the last stretch of making a decent display to run 
linuxcnc in/on. 

I traded the jessie-lite install on the r-pi for the full install.  But I 
made several trips back to the card reader fixing this and that while it 
wasn't running, but in a couple hours, I managed to change the /home/pi 
to /home/gene, fixed the passwd, group and sudoers files up so that I am 
now user 1000 and can do as I wish.  Including using synaptic as the 
package manager.

Having the full install made a huge difference as I can now run linuxcnc 
from an xterm.  And it runs at around 15 to 20 updates a second, all on 
the r-pi. I can tolerate that with one exception, the mouse is on a 
flexible hose, running around in cold molasses. You move it, using 
muscle memory, and even an inch on screen takes around a second for the 
mouse pointer to get to where you moved it to. It just sort of ooozes 
off in the general direction, then you look, and wait for it to stop    
  
so you can make the final move in the direction toward what you want to 
hit.  Wierd.  But that definitely needs fixed.

Everything else is ah&elbows & greasy hands at this point, its ALL 
running on the raspberry3b, fast enough to be usable.

ATM both my back (old age and arthritis) and my arm hurts, the arm from 
patting myself on the back. ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

On Tuesday 29 November 2016 04:18:09 Antoine Martin wrote:

> >>>> If you exclude the 4k fullscreen video use case - which is a
> >>>> worst case scenario for remote display (there are tricks to deal
> >>>> with that too if you are willing to make sacrifices), then screen
> >>>> updates are actually much more manageable, even on a 1Gbps shared
> >>>> link.
> >>>
> >>> nope. not really. do the math. buy a few arm dev boards. :) find
> >>> out that you won't get 1gigabit. even 100mbit is pushing things.
> >>
> >> Even 100mbit is perfectly usable for remote access provided you use
> >> the right tools and make some sacrifices. FYI: 4K@60 "fits" in H264
> >> ~60Mbps. But again, as I said above, just don't expect to handle
> >> fullscreen video on arm where *we* don't support hardware H264
> >> decoding. (though other tools might)
> >
> > but we're not talking video streams. we're talking x11.
>
> I believe the OP's requirement is to run an X11 application on one
> system and display it on the arm system, at a better framerate than is
> being offered currently by X11-over-ssh.

Slight correction, the application that is generating the image data, is 
running on the pi 3b, the system doing the viewing and control, is to 
run on the odroid-c2, which does have the gfx horsepower and memory to 
do it.

It also has 4 gpu's, which are so new that linux & X does not use them 
ANAICT. But I'd assume its the future for these arm based SBC's.

> Or at least, that's the angle I choose to see since that's exactly
> what xpra does ;)
>
> Seriously, we're not just a little bit proud of the fact that users
> have a relatively smooth experience with 4K monitors over 100Mbps
> connections considering that their display link will top 25Gbps.
> It took years of effort and we're finally releasing a v1.0 this week.
>
> > and with x11 to push
> > pixels across a network basically means xputimage and that means the
> > bandwidth requirements i have given (or sending the draw calls and
> > as discussed this is pretty much dead for various reasons).
>
> IME, users usually don't care much about what transport is used as
> long as the solution satisfies their requirements.

Precisely. Git-r-done at a usable/reasonable frame rate.

> >> And obviously, if you want lossless you probably aren't doing
> >> 20fps. At this point it is probably best to ask the OP exactly
> >> *what* he needs forwarded at 20fps.
> >>
> >>> the days where your clients upload some monochrome 1 bit bitmaps
> >>> and then just render with xfillarc/xcopyarea etc. etc. are kind of
> >>> over.
> >>
> >> Definitely over.
> >>
> >>> today data is 32bpp
> >>> with lots of new client-side generated data all the time and mopre
> >>> and more clients try and use opengl to get acceleration and speed
> >>> and that's really a local-only thing these days. yes i know of glx
> >>> indirect rendering. get that to work over a network to an arm
> >>> board which is egl/gles... :)
> >>
> >> Yes, that's exactly the use cases that we handle.
> >>
> >> Cheers
> >> Antoine
> >>
> >> http://xpra.org/
> >
> > xpra is its own display system effectively separate from x11.
>
> Sort of. Nitpick: Xpra is an X11 compositing window manager and we use
> a completely stock / unmodified / distro supplied X11 server, the
> clients are native however (X11, OpenGL, HTML5) and the wire protocol
> has nothing to do with X11 at all.
>
> Cheers
> Antoine
>
> > at least in terms
> > of display as x11 protocol supports no forms of compression (let
> > along lossy compression) of pixel data. xpra is a separate display
> > tech much like rdp, miracast, vnc etc. would be. :)
>
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

On Tuesday 29 November 2016 03:24:35 Carsten Haitzler wrote:

> On Tue, 29 Nov 2016 10:58:37 +0700 Antoine Martin 
 said:
[...]
> > http://xpra.org/
>
> xpra is its own display system effectively separate from x11. at least
> in terms of display as x11 protocol supports no forms of compression
> (let along lossy compression) of pixel data. xpra is a separate
> display tech much like rdp, miracast, vnc etc. would be. :)

This also sounds appealing. I'll see if its available for both of these 
beasts.

Thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

On Tuesday 29 November 2016 02:40:45 Alan Coopersmith wrote:

> On 11/28/16 07:58 PM, Antoine Martin wrote:
> > Even 100mbit is perfectly usable for remote access provided you use
> > the right tools and make some sacrifices. FYI: 4K@60 "fits" in H264
> > ~60Mbps. But again, as I said above, just don't expect to handle
> > fullscreen video on arm where *we* don't support hardware H264
> > decoding. (though other tools might)
>
> But we're talking the X11 protocol, not H264.  X11 doesn't compress
> video at all - you need an external proxy to do that, and since LBX
> support was dropped from the X server years ago, that leaves ssh X
> forwarding with compression, or picking an alternate protocol such as
> VNC or RDP.

Since we are talking about my needs, and you mention vnc, its now part of 
the latest raspian download, which I didn't have yet, but the iso is 
trickling in now. It is not part of the odroids ubtuntu-16.04 LTS 
install so I'll have to see about how to acquire the free home version.

That assumes that it can function in the presence of a x server on the 
droid whose listen function is turned off, presumably by removing the 
code.  Can it?

Thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

On Monday 28 November 2016 22:58:37 Antoine Martin wrote:

> On 29/11/16 10:28, Carsten Haitzler (The Rasterman) wrote:
> > On Tue, 29 Nov 2016 09:43:54 +0700 Antoine Martin 
 said:
> >> On 29/11/16 07:57, Carsten Haitzler (The Rasterman) wrote:
> >>> On Mon, 28 Nov 2016 17:03:17 -0500 Gene Heskett 
 said:
> >>>> On Monday 28 November 2016 13:12:03 Alan Coopersmith wrote:
> >>>>> On 11/27/16 04:29 PM, Gene Heskett wrote:
> >>>>>> Okay Alan, I've had 3 or 4 folks over the last 36 hours claim
> >>>>>> that X is its own forwarding agent, why am I even using ssh?
> >>>>>> saying I'm not needing ssh at all.
> >>>>>
> >>>>> X can connect directly, but without the encryption & compression
> >>>>> that ssh adds when it acts as the forwarding agent.  ssh has
> >>>>> been the modern recommended solution for years - all major
> >>>>> distros have started X with "-nolisten tcp" for over a decade,
> >>>>> and recent versions of Xorg made that the default, such that you
> >>>>> need to go specify "-listen tcp" to enable the old direct TCP
> >>>>> connection method now if you want to avoid ssh.
> >>>>>
> >>>>>> So, where can I find the definitive tut on doing this because
> >>>>>> our attempts are failing?  What I was able to find on the xorg
> >>>>>> web pages last night was up to 3 major versions out of date.  I
> >>>>>> need a tut that deals with X11R7 and up.  Is there such a
> >>>>>> thing?  My google-fu is failing me.
> >>>>>
> >>>>> Our recommendation for X11R7 remote connections is "Use SSH X11
> >>>>> Forwarding."
> >>>>
> >>>> Which works but at very lethargic speeds. 3, 4 frames a second. 
> >>>> I need 20 or more. This odroid64, with at least 3 gpu's is said
> >>>> to be able to do a 4k display at 60 frames a second.
> >>>
> >>> that'd be simply display REFRESH. not actual rendering of content.
> >>> and forget REMOTE display over ssh over a bottleneck of a network
> >>> device. forget trying to get anything like high performance over a
> >>> network connection when it comes to display. don't even bother.
> >>> it's a waste of time.
> >>
> >> I beg to differ. An arm CPU certainly makes this more of a
> >> challenge, but it is not a lost cause... just don't use SSH
> >> forwarding, some tuning IS required.
> >
> > it has nothing to do with an arm cpu... it's the network. see below.
> > if someone is quoting "this arm SoC can do UHD at 60hz" then you're
> > in fantasy land thinking you can even get anywhere NEAR that. even
> > 1080p at 20hz would need 1.3 gigabit of pure bandwidth on the
> > network without any protocol etc. overhead. so let's round that up
> > to 1.5 gigabit allowing for overhead and other misc traffic. you'd
> > have to keep that bandwidth fed solidly ANd also copy data to the
> > framebuffer etc.
> >
> >>> if it displays at ALL - be
> >>> happy. to provide updated pixels at 60hz for a 4k display would
> >>> require a 16 GIGABIT network... with NO OTHER TRAFFIC on it at
> >>> all. and no network packet/protocol overhead. so let's make that
> >>> 20 gigabit. that's assuming xputimage with 24bpp images (padded
> >>> out to 32bpp as that's how xputimage works). that does not account
> >>> for bottlenecks outside the network itself (the system at either
> >>> end and it's tpc/ip stack, kernel, memcpy's etc. etc.).
> >>
> >> I don't think the OP is trying to watch a 4K video over TCP, rather
> >> stating that his hardware is capable of pushing 4k@60 pixels, which
> >> is why he was expecting better results.
> >
> > see above. 1080p @ 20hz would exceed any network adaptor he has. i
> > don't know what this odroid64 is, but if he;s talking of the
> > odroid's from hardkernel, then the TOP of the line they have is the
> > xu4 (or xu3 - not available anymore but identical to the xu4 simply
> > with more usb ports, more display ports etc.). the xu3 has a gigabit
> > port. let's get to some reality...
> >
> > i have an xu3. i also have a pc. both with gigabit ethernet ports
> > attached to a gigabit switcch. gu

Re: Question about X on the arm's.

[Gene Heskett]

On Monday 28 November 2016 21:43:54 Antoine Martin wrote:

> On 29/11/16 07:57, Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 28 Nov 2016 17:03:17 -0500 Gene Heskett 
 said:
> >> On Monday 28 November 2016 13:12:03 Alan Coopersmith wrote:
> >>> On 11/27/16 04:29 PM, Gene Heskett wrote:
> >>>> Okay Alan, I've had 3 or 4 folks over the last 36 hours claim
> >>>> that X is its own forwarding agent, why am I even using ssh?
> >>>> saying I'm not needing ssh at all.
> >>>
> >>> X can connect directly, but without the encryption & compression
> >>> that ssh adds when it acts as the forwarding agent.  ssh has been
> >>> the modern recommended solution for years - all major distros have
> >>> started X with "-nolisten tcp" for over a decade, and recent
> >>> versions of Xorg made that the default, such that you need to go
> >>> specify "-listen tcp" to enable the old direct TCP connection
> >>> method now if you want to avoid ssh.
> >>>
Unfortunately, I have told it to listen, but its apparently disabled 
internally.

I can launch it with this command line:

exec /usr/bin/X -listen tcp "@"
but when I look with htop, the option is shown as -nolisten tcp, so of 
course it doesn't work.  I'd like to take my walking stick and go 
calling on whoever made that choice because it saved 50k of object code.

That has now been pointed out as a bug on the droid forums. So we'll see 
how that goes over.

> >>>> So, where can I find the definitive tut on doing this because our
> >>>> attempts are failing?  What I was able to find on the xorg web
> >>>> pages last night was up to 3 major versions out of date.  I need
> >>>> a tut that deals with X11R7 and up.  Is there such a thing?  My
> >>>> google-fu is failing me.
> >>>
> >>> Our recommendation for X11R7 remote connections is "Use SSH X11
> >>> Forwarding."
> >>
> >> Which works but at very lethargic speeds. 3, 4 frames a second.  I
> >> need 20 or more. This odroid64, with at least 3 gpu's is said to be
> >> able to do a 4k display at 60 frames a second.
> >
> > that'd be simply display REFRESH. not actual rendering of content.
> > and forget REMOTE display over ssh over a bottleneck of a network
> > device. forget trying to get anything like high performance over a
> > network connection when it comes to display. don't even bother. it's
> > a waste of time.
>
> I beg to differ. An arm CPU certainly makes this more of a challenge,
> but it is not a lost cause... just don't use SSH forwarding, some
> tuning IS required.
>
> > if it displays at ALL - be
> > happy. to provide updated pixels at 60hz for a 4k display would
> > require a 16 GIGABIT network... with NO OTHER TRAFFIC on it at all.
> > and no network packet/protocol overhead. so let's make that 20
> > gigabit. that's assuming xputimage with 24bpp images (padded out to
> > 32bpp as that's how xputimage works). that does not account for
> > bottlenecks outside the network itself (the system at either end and
> > it's tpc/ip stack, kernel, memcpy's etc. etc.).
>
> I don't think the OP is trying to watch a 4K video over TCP, rather
> stating that his hardware is capable of pushing 4k@60 pixels, which is
> why he was expecting better results.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

On Monday 28 November 2016 18:11:29 Thomas Lübking wrote:

> On Mon, Nov 28, 2016 at 11:15:52AM -0500, Gene Heskett wrote:
> >> remove the '-nolisten tcp' from its launch of
> >> exec /usr/bin/X "$@"
> >> in xinit/xserverrc, and that would enable it, no one else has said
> >> to just remove the "no".
> >>
> >> What would be the nmap line to show that it is indeed listening?
> >
> >Well, that didn't get me a listener according to an nmap scan of the
> >odroid server from this machine, after I was logged into the
> >odroid "server" and x was running.
>
> Did you ensure the server is started invoking this file (by startx)?
> ps aux | grep listen

gene@odroid64:~$ sudo ps aux | grep listen
[sudo] password for gene: 

root   797  0.0  1.9 271380 33600 tty7 Ssl+ 20:50   
0:02 /usr/lib/xorg/Xorg -core :0 -seat 
seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

gene  4114  0.0  0.0   5564   908 pts/8S+   23:48   0:00 
grep --color=auto listen

The default was changed from listen to nolisten about 18 months back, but 
the -listen directive/argument is according to Alan Coopersmith at Xorg, 
supposed to over ride it and turn it back on. Methinks the odroid 
builders took advantage of that to get rid of 100k of object code.  So I 
have challenged the odroid people to actually make it work.
>
> nmap -p 6000 
> should then be open if X runs on display :0
>
> In doubt, start the server by hand "Xorg -listen tcp :0" to test the
> behavior.
>
That server starts automatically.  No clue it it shut down with 
ctl+alt+del.  No, its been hijacked to start a logout session for me.

The line that starts it, xinit/xsessionrc specifically says -listen tcp 
as an argument for /usr/bin/X

> Cheers,
> Thomas
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

On Monday 28 November 2016 13:12:03 Alan Coopersmith wrote:

> On 11/27/16 04:29 PM, Gene Heskett wrote:
> > Okay Alan, I've had 3 or 4 folks over the last 36 hours claim that X
> > is its own forwarding agent, why am I even using ssh? saying I'm not
> > needing ssh at all.
>
> X can connect directly, but without the encryption & compression that
> ssh adds when it acts as the forwarding agent.  ssh has been the
> modern recommended solution for years - all major distros have started
> X with "-nolisten tcp" for over a decade, and recent versions of Xorg
> made that the default, such that you need to go specify "-listen tcp"
> to enable the old direct TCP connection method now if you want to
> avoid ssh.
>
> > So, where can I find the definitive tut on doing this because our
> > attempts are failing?  What I was able to find on the xorg web pages
> > last night was up to 3 major versions out of date.  I need a tut
> > that deals with X11R7 and up.  Is there such a thing?  My google-fu
> > is failing me.
>
> Our recommendation for X11R7 remote connections is "Use SSH X11
> Forwarding."
>
Which works but at very lethargic speeds. 3, 4 frames a second.  I need 
20 or more. This odroid64, with at least 3 gpu's is said to be able to 
do a 4k display at 60 frames a second.

> Unfortunately, so few people are willing to help write X11 docs that
> there isn't a whole lot of stuff written since the X Consortium
> stopped paying doc writers in the mid 90's.

Yikes! NDW I cannot find uptodate docs & tuts.

Thanks Alan, I appreciate the candor.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

On Monday 28 November 2016 08:49:03 Gene Heskett wrote:

> On Monday 28 November 2016 07:31:07 Thomas Lübking wrote:
> > On Sun, Nov 27, 2016 at 07:29:14PM -0500, Gene Heskett wrote:
> > >Okay anyone, I've had 3 or 4 folks over the last 36 hours claim
> > > that X is its own forwarding agent, why am I even using ssh?
> > > saying I'm not needing ssh at all.
> >
> > pass it "-listen tcp", it should open a connection on port 6000+n
> > (where n is the server, starting with 0) and you can "export
> > DISPLAY=remotedomain:0.0" to run X11 clients on that server.
> >
> > Notice that this is no good idea unless on a local, friendly
> > network.
>
> It is, I am the only user, and its all behind dd-wrt, which has not
> been penetrated in over a decade. If it wasn't for the need of a
> switch that allows these machines access to the net for updates and
> such, this particular cable could be 10" long. But since there is a
> gigabit switch on the other side of the room, the cat6's will be 50'
> each by the time they are fastened down with romex staples.
>
> The source SBC, an R-Pi 3b which is running an up to date raspian
> (debian Jessie built for arm) is running LinuxCNC, which is commanding
> a 1500 lb 11x36 Sheldon lathe about 65 yo, will be feeding the display
> data to a odroid64, which is claimed to be able to drive a 4k display
> with a 60 Hz refresh rate.  But when doing so over the ssh xforwarding
> encrypted path, is so slow the screen refresh is about 3x a second.
> Very distracting, and potentially dangerous when the machine can move
> 2 or 3 inches in that time frame.  Changing ssh to a faster protocol
> only got it up to 5 or 6 frames. I need to get that flicker rate up to
> a less distracting rate, something above 20 Hz if possible.  The raspi
> looks at the  machine and takes corrective action every millisecond
> but it hasn't got the memory to do the x at the same time. The
> odroid64 has 2x the memory and more gpu's and if I can get the data to
> it, ought to be ble to do it in real time.
>
> > Also, all caveats with "modern" toolkits apply here the same (they
> > tend to be dead slow over tcp because of the massive image putting,
> > you'll only get indirect GL etcetc.)
> >
> > Cheers,
> > Thomas
>
> We will see, if I can make it work. I was told I was supposed to just
> remove the '-nolisten tcp' from its launch of
> exec /usr/bin/X "$@"
> in xinit/xserverrc, and that would enable it, no one else has said to
> just remove the "no".
>
> What would be the nmap line to show that it is indeed listening?

Well, that didn't get me a listener according to an nmap scan of the 
odroid server from this machine, after I was logged into the 
odroid "server" and x was running.

The Xorg.0.log contains zero info about 'listen' directives. No mention 
at all.
gene@odroid64:/var/log$ grep listen Xorg.0.log
gene@odroid64:/var/log$ 

Where else do I need check and adjust to "enable" this listen function?

Thank you Thomas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

On Monday 28 November 2016 07:31:07 Thomas Lübking wrote:

> On Sun, Nov 27, 2016 at 07:29:14PM -0500, Gene Heskett wrote:
> >Okay anyone, I've had 3 or 4 folks over the last 36 hours claim that
> > X is its own forwarding agent, why am I even using ssh? saying I'm
> > not needing ssh at all.
>
> pass it "-listen tcp", it should open a connection on port 6000+n
> (where n is the server, starting with 0) and you can "export
> DISPLAY=remotedomain:0.0" to run X11 clients on that server.
>
> Notice that this is no good idea unless on a local, friendly network.

It is, I am the only user, and its all behind dd-wrt, which has not been 
penetrated in over a decade. If it wasn't for the need of a switch that 
allows these machines access to the net for updates and such, this 
particular cable could be 10" long. But since there is a gigabit switch 
on the other side of the room, the cat6's will be 50' each by the time 
they are fastened down with romex staples.

The source SBC, an R-Pi 3b which is running an up to date raspian (debian 
Jessie built for arm) is running LinuxCNC, which is commanding a 1500 lb 
11x36 Sheldon lathe about 65 yo, will be feeding the display data to a 
odroid64, which is claimed to be able to drive a 4k display with a 60 Hz 
refresh rate.  But when doing so over the ssh xforwarding encrypted 
path, is so slow the screen refresh is about 3x a second. Very 
distracting, and potentially dangerous when the machine can move 2 or 3 
inches in that time frame.  Changing ssh to a faster protocol only got 
it up to 5 or 6 frames. I need to get that flicker rate up to a less 
distracting rate, something above 20 Hz if possible.  The raspi looks at 
the  machine and takes corrective action every millisecond but it hasn't 
got the memory to do the x at the same time. The odroid64 has 2x the 
memory and more gpu's and if I can get the data to it, ought to be ble 
to do it in real time.

> Also, all caveats with "modern" toolkits apply here the same (they
> tend to be dead slow over tcp because of the massive image putting,
> you'll only get indirect GL etcetc.)
>
> Cheers,
> Thomas


We will see, if I can make it work. I was told I was supposed to just 
remove the '-nolisten tcp' from its launch of 
exec /usr/bin/X "$@"
in xinit/xserverrc, and that would enable it, no one else has said to 
just remove the "no".

What would be the nmap line to show that it is indeed listening?

Thank you Thomas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

On Friday 25 November 2016 12:32:22 Alan Coopersmith wrote:

> On 11/21/16 02:41 PM, Gene Heskett wrote:
> > I am assuming the X built for it is single threaded, and it could be
> > made more pleasant to use if it scattered its jobs about the 4 cores
> > in the typical arm cpu.
> >
> > Is there a build switch that could accomplish this?
>
> No - making the X server fully multi-threaded would be a major
> rewrite, not just flipping a build switch.   Past attempts to do so
> weren't very successful, as they all ended up bottlenecking on the
> write lock to the frame buffer.   Instead things like input processing
> (previously done via asynchronous signal handlers) have been moved to
> other threads, and a lot of graphics rendering has effectively moved
> to other threads by virtue of doing it in client processes instead of
> in the X server itself.

Okay Alan, I've had 3 or 4 folks over the last 36 hours claim that X is 
its own forwarding agent, why am I even using ssh? saying I'm not 
needing ssh at all.

So, where can I find the definitive tut on doing this because our 
attempts are failing?  What I was able to find on the xorg web pages 
last night was up to 3 major versions out of date.  I need a tut that 
deals with X11R7 and up.  Is there such a thing?  My google-fu is 
failing me.

Thanks Alan.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

On Friday 25 November 2016 07:21:10 Boszormenyi Zoltan wrote:

> 2016-11-25 11:24 keltezéssel, Gene Heskett írta:
> > On Monday 21 November 2016 17:41:45 Gene Heskett wrote:
> >> Greetings X experts;
> >>
> >> I bought a monitor that should have been able to do 1920x1080p60Hz.
> >> One would expect thats a given when the card gets $140 lighter
> >> carrying it out past the RF stuff in Wallies front door frame, so I
> >> just bought 2 of the faster SBC's like the r-pi 3b but the one that
> >> will display what the r-pi 3b puts out, claimed to be a bit faster.
> >>
> >> It wasn't until I googled for its specs last night and discovered
> >> its max is 1366x768 that I actually got a picture out of it hooked
> >> to anything except the r-pi.
> >>
> >> My question has to do with the rendering and screen refresh rate,
> >> which is obviously about 1/4 of the speed an old single core, x86
> >> P4.
> >>
> >> I am assuming the X built for it is single threaded, and it could
> >> be made more pleasant to use if it scattered its jobs about the 4
> >> cores in the typical arm cpu.
> >>
> >> Is there a build switch that could accomplish this? This is a quad
> >> core 64 bit arm cpu, running at its default clock of 1.5GHz which
> >> it seems like should have the ponies to handle the load.  More heat
> >> sink maybe.
> >
> > Ping?
>
> Rasterman replied to you soon after your mail. See
> https://lists.x.org/archives/xorg/2016-November/058447.html

And which I somehow missed, but it is here, my apologies.

> >> Is there anything I can do, considering its only other job is
> >> serviceing the keyboard and rodent?
> >
> > I've since found, using htop, that X is not the heaviest cpu hog,
> > ssh is, about 3x that of X.
> >
> > What cipher is the least intensive cpu load? I've found these things
> > do not have telnet services installed.
>
> How about arcfour or one of its variants?
> On a trusted the LAN even a slow Geode LX can produce more than
> 100Mbit LAN bandwith. With more CPU intensive ciphers the speed
> is reduced to around 2MByte/sec.

I see by the listing of a -Q cipher that there several arc4's available.
On the raspi, running raspian:
gene@raspberrypi:/etc/ssh $ ssh -Q cipher
3des-cbc
blowfish-cbc
cast128-cbc
arcfour
arcfour128
arcfour256
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-...@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-...@openssh.com
aes256-...@openssh.com
chacha20-poly1...@openssh.com

And on the odroid, running a 3 year older kernel:
3des-cbc
blowfish-cbc
cast128-cbc
arcfour
arcfour128
arcfour256
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-...@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-...@openssh.com
aes256-...@openssh.com
chacha20-poly1...@openssh.com

So it looks like they match, but in making a choice, is there a url that 
discusses the relative merits of each, such as the cpu loading? In my 
case a well done report would simplify the choice & let me get back to 
the bigger picture.

I would assume that logging out, and restarting sshd from each machines 
keyboard, or a reboot of all involved would be required. I'll google for 
some docs, but just because it is security related, they seem to be 
squirreled away in darker corners.

Thank you very much.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question about X on the arm's.

[Gene Heskett]

On Monday 21 November 2016 17:41:45 Gene Heskett wrote:

> Greetings X experts;
>
> I bought a monitor that should have been able to do 1920x1080p60Hz.
> One would expect thats a given when the card gets $140 lighter
> carrying it out past the RF stuff in Wallies front door frame, so I
> just bought 2 of the faster SBC's like the r-pi 3b but the one that
> will display what the r-pi 3b puts out, claimed to be a bit faster.
>
> It wasn't until I googled for its specs last night and discovered its
> max is 1366x768 that I actually got a picture out of it hooked to
> anything except the r-pi.
>
> My question has to do with the rendering and screen refresh rate,
> which is obviously about 1/4 of the speed an old single core, x86 P4.
>
> I am assuming the X built for it is single threaded, and it could be
> made more pleasant to use if it scattered its jobs about the 4 cores
> in the typical arm cpu.
>
> Is there a build switch that could accomplish this? This is a quad
> core 64 bit arm cpu, running at its default clock of 1.5GHz which it
> seems like should have the ponies to handle the load.  More heat sink
> maybe.
>
Ping?

> Is there anything I can do, considering its only other job is
> serviceing the keyboard and rodent?

I've since found, using htop, that X is not the heaviest cpu hog, ssh is, 
about 3x that of X.

What cipher is the least intensive cpu load? I've found these things do 
not have telnet services installed.

Comments and suggestions welcome.

> Thanks everybody.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Question about X on the arm's.

[Gene Heskett]

Greetings X experts;

I bought a monitor that should have been able to do 1920x1080p60Hz.
One would expect thats a given when the card gets $140 lighter carrying 
it out past the RF stuff in Wallies front door frame, so I just bought 2 
of the faster SBC's like the r-pi 3b but the one that will display what 
the r-pi 3b puts out, claimed to be a bit faster.

It wasn't until I googled for its specs last night and discovered its max 
is 1366x768 that I actually got a picture out of it hooked to anything 
except the r-pi.

My question has to do with the rendering and screen refresh rate, which 
is obviously about 1/4 of the speed an old single core, x86 P4.

I am assuming the X built for it is single threaded, and it could be made 
more pleasant to use if it scattered its jobs about the 4 cores in the 
typical arm cpu.

Is there a build switch that could accomplish this? This is a quad core 
64 bit arm cpu, running at its default clock of 1.5GHz which it seems 
like should have the ponies to handle the load.  More heat sink maybe.

Is there anything I can do, considering its only other job is serviceing  
the keyboard and rodent?

Thanks everybody.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Flickering single display in multi-head XRandR setup

[Gene Heskett]

On Saturday 26 March 2016 01:55:53 Felix Miata wrote:

> Gene Heskett composed on 2016-03-25 20:52 (UTC-0400):
> > Felix Miata wrote:
>
> ...
>
> >> Looks like a 3-wire cord to me, and $14.99 in the current sale
> >> catalog.
> >
> > By golly gee, I do believe you are correct, so they've "fixed" that
> > problem. And 15 bucks is less than I paid for one 25 years ago when
> > smd stuff was just coming on the scene.  But I'm not on their spam
> > list so I don't get the pdf version of the catalog...
>
> MCM catalogs seem to show up in snail mail here every 3-6 weeks or so.
> I usually have at least 3 that haven't expired yet. I can't imagine
> how anyone who's ever ordered from them could not have catalogs
> around, unless they're being moved straight from mailbox to trash or
> recycle bin. :-p

I get one of those from time to time, not that often though, it gets 
scanned while I'm eating dinner and unless there is something I need, it 
goes into the out bin.  The midden heap is deep enough as it is.

There ought to be a law that two packrats can't marry...

> > Thanks for the tickle to make me go look at it again.
> >
> :-)


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Flickering single display in multi-head XRandR setup

[Gene Heskett]

On Friday 25 March 2016 17:47:48 Felix Miata wrote:

> Gene Heskett composed on 2016-03-25 15:55 (UTC-0400):
> >> http://www.mcmelectronics.com/product/TENMA-21-8230-/21-8230
> >> wouldn't do it?
> >
> > Possibly, that looks a lot like the one I used (handles are
> > identical) back in the later 90's but with different tips.
>
> Looks like a 3-wire cord to me, and $14.99 in the current sale
> catalog.

By golly gee, I do believe you are correct, so they've "fixed" that 
problem. And 15 bucks is less than I paid for one 25 years ago when smd 
stuff was just coming on the scene.  But I'm not on their spam list so I 
don't get the pdf version of the catalog.  Which is odd, because I have 
bought stuff from them in the last year, a bag of slot interruptor 
opto's to make a quadrature encoder for a milling machine spindle.  
Specifically the spindle in a Grizzly G0704 milling machine.

Thanks for the tickle to make me go look at it again.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Flickering single display in multi-head XRandR setup

[Gene Heskett]

On Friday 25 March 2016 13:23:52 Felix Miata wrote:

> Gene Heskett composed on 2016-03-25 09:29 (UTC-0400):
> > the U.S. industry, since General Cement is gone, cannot sell me a
> > tweezer-like soldering iron needed to remove them so fresh ones can
> > be put in their place.  And even the GC iron sold 20+ years ago had
> > to be run on a powerstat set for as low as 60 volts else it ran so
> > hot it destroyed the board.
>
> http://www.mcmelectronics.com/product/TENMA-21-8230-/21-8230 wouldn't
> do it?

Possibly, that looks a lot like the one I used (handles are identical) 
back in the later 90's but with different tips.  Two problems, the major 
one being that it STILL has a 2 wire line cord, so no static grounding 
and the heater barrels are some sort of metal that isn't conducive to 
making a good electrical ground connection to, and it needs to be run on 
a small powerstat so you can turn the voltage down to the 60-65 range 
otherwise its way the hell and gone too hot 4 or 5 minutes after you 
turn it on, and when doing the caps in a DVC-pro vcr, it will be on for 
at least 6 hours of the working day.  Even then, I found it hot enough 
to cause the pencil eraser sized caps to explode as I was removing them.  
The copper tips are always annealed and very easily bend as you compress 
that spring to bring the tips to a spacing suitable for warming both 
side contacts, and that 20 thousandths of bend puts the tips in full 
contact with the sides of the caps & they pop about like Orville 
Redenbauchers finest.

But as usual, it was the best we had at the time, so when in Rome...

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Flickering single display in multi-head XRandR setup

[Gene Heskett]

On Friday 25 March 2016 07:19:44 Andreas Mohr wrote:

> Hi,
>
> On Fri, Mar 25, 2016 at 11:03:36AM +0100, martin f krafft wrote:
> > Hi Andreas,
> >
> > Thank you for taking your time to reply. I've since followed up
> > having found the problem, and I think it must be one of the DP ports
> > on the graphics card.
>
> Ooook.
>
> > Now, you write:
> > > Perhaps unthinkable, but the connectors of the card might be
> > > implemented / wired up asymmetrically, e.g. due to an ickily
> > > varying length of traces, or EMI issues.
> >
> > This leads me to believe that the connector hardware itself could be
> > at fault. Seriously, is DP *that* finicky and subject to connection
> > failures? I'd have thought that it being 2016, the industry would
> > have finally gotten the hang of it, especially after screwing up
> > HDMI so badly.
>
> Hmm, I was writing that focussing on PCB-side implementation etc.,
> but of course mechanical connection issues (including soldering
> issues) likely are more dominant (when doing failure diagnosis,
> one likely should focus on more "mechanical" / electro-physical parts
> such as connectors, fuses, capacitors, transformers, ... initially,
> since these are much more prone to failure
> due to their inherent wear and tear - movement, thermo-related etc.).
>
>
> Nice to hear that this seems nailed now.
>
> Andreas Mohr

Speaking as a Certified Electronics Technician, which I am, I can often 
refine the mechanical part, not to a flaky connector, although its 
possible, but far more often it will be found to be a surface mounted 
low voltage electrolytic capacitor that has failed by loss of an 
internal connection.  Overall, the failure rate of those is 100x that of 
any other part on the average PCB. The failure mechanism is a high 
Equivalent Series Resistance, and it takes a meter designed to read this 
ESR, to find the problem, something 99.9% of the digital meters today do 
not have as its a completely different circuit that measures it.  
Special meters that do measure it can be had even as a kit you build, 
but the best of the lot is the Capacitor Wizard, at about $200 USD a 
copy.

Worse, the U.S. industry, since General Cement is gone, cannot sell me a 
tweezer-like soldering iron needed to remove them so fresh ones can be 
put in their place.  And even the GC iron sold 20+ years ago had to be 
run on a powerstat set for as low as 60 volts else it ran so hot it 
destroyed the board.

That is why so much of our electronics is now a one shot deal, plug it in 
and use it till it fails, and when it fails, go to the store and get 
another to plug into that function/position.  No repair is possible at a 
cost that makes repairing it feasable.  Toss in that such people are a 
dying breed and are not being replaced by the younger generation. I did 
do that, since 1949 for a living, but now at 81, my hands are losing the 
steadiness needed.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

unclutter again

[Gene Heskett]

Greetings;

I had unclutter setup 
-idle .1 -reset

But that was too quick a hide for email since I have a folder or 2 that 
when advancing into, display the spinning dumbell while it finding the 
new message to show me.  And even on this machine I may spin for 15 or 
more seconds as theres quite a few gigabytes of mail files in that 
directory.

So I though it would be useful to reset the idle time to 30 seconds.  I 
made that change in /etc/default/unclutter, but X doesn't seem to have a 
restart mechanism like the stuff in init.d does, as its normally started 
as 90unclutter in /etc/X11/Xsession.d.
So I sent it a SIGHUP, which killed it rather than causing it to re-read 
its config, effectively restarting it.

So I started it by hand with a sudo prefix and an & terminator.  htop 
shows both the "sudo unclutter -idle 30 -reset", and the 
"unclutter -idle 30 -reset"
processes running, but its not even working for that terminal screen.  

Sending the sudo version a SIGTERM kills both.

Because X is very poor at remembering what I have running and what screen 
its running on, a logout, and log back in, it is about a 10 minute 
process to get back to the everything running in the correct workspace. 
I have to not only figure out the mishmash of multitab terminals it 
reopens on whatever workspace I am on by the time it gets around to 
restoring them. This includes the time spent moving that terminal to the 
workspace it belongs in, restarting a sudo htop, sudo tail messages, 
another tail on fetchmails log, switch to workspace 2 and initilize 3 
sessions of sshfs and 3 sessions of ssh-Y to my other machines, starting 
kmail on this workspace, and an incoming mailwatcher script that tells 
kmail to go get the mail after a new mail has been written 
to /var/spool/mail.

Very occasionally it will restart kmail too, but probably piled up on 
workspace 1 with the rest of the terminal sessions.

So how can one effectively restart a process normally started by a file 
in /etc/X11/Xsession.d/90unclutter?

Thank you.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Mouse blanker function?

[Gene Heskett]

On Monday 28 September 2015 23:57:24 Alan Coopersmith wrote:

> On 09/28/15 08:36 PM, Gene Heskett wrote:
> > Greetings all;
> >
> > Is there such a critter as a mouse blanker in the xorg kit of
> > utilities?
>
> Sorry, I've never heard of a "mouse blanker" before - what would such
> a program do?

It shuts off the pointer when you start typing, and brings it back when 
the mouse is moved.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Mouse blanker function?

[Gene Heskett]

Greetings all;

Is there such a critter as a mouse blanker in the xorg kit of utilities?

Thank you.
 
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: intel atom D525MW w/i915 onboard gfx vs 16x9 monitor

[Gene Heskett]

On Saturday 18 July 2015 08:35:40 Dan Ritter wrote:
> On Sat, Jul 18, 2015 at 12:06:13AM -0400, Gene Heskett wrote:
> > Greetings all;
> >
> > Does anyone know how to get a square pixel on this gfx set?
> >
> > It works well on a 4x3 monitor, but circles are squashed on a 16x9.
>
> Sounds like you need to set DisplaySize in the Monitor section
> of your Xorg.conf. The values are in millimeters, high then
> wide.
>
> -dsr-
I think what I just did, worked, see my reply to Felix just now.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [solved] intel atom D525MW w/i915 onboard gfx vs 16x9 monitor

[Gene Heskett]

On Saturday 18 July 2015 08:06:23 Felix Miata wrote:
> Gene Heskett composed on 2015-07-18 07:22 (UTC-0400):
> > Xorg.0.log is in my other reply, Felix.  I'm just up, need a quart
> > of coffee I haven't made yet to function correctly. :-\
>
> Clearly. From that post:
>
> (xrandr)
> DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y
> axis) 509mm x 286mm
> HDMI-1 disconnected (normal left inverted right x axis y axis)
> VGA-1 disconnected (normal left inverted right x axis y axis)
> (log)
> [27.790] (II) intel(0): Output LVDS1 connected
> [27.790] (II) intel(0): Output VGA1 connected
>
> So, you've given xrandr output from one machine, and Xorg.0.log output
> from a different machine.
>
> > In any event, the machines in question do not have either
> > an /etc/X11/xorg.conf, nor an /etc/X11/xorg.conf.d
>
> That's normal, designed for automagic configuration. Apparently
> automagic for you is not working, so you'll need to construct either
> an xrandr script, or an xorg.conf*, as I suggested and provided links
> to that end in prior reply.
>
> So, which is from the Atom machine, the one with two displays
> connected, or the one with one? And, what is the proper other output
> from the Atom machine?

Something apparently had the screen locked during my previous attempts.
XFCE, settings/display was using a laptop default, selecting the AOL 
monitor button and bringing up the multiselector, there was a 13##x768 
option that I clicked, and one second later I had a screen, so I clicked 
on save.

Then, ran LinuxCNC, and the circles from an encoder disk backplot are now 
perfect.  If it holds over a reboot, I am a happy camper.

Thanks Felix.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: intel atom D525MW w/i915 onboard gfx vs 16x9 monitor

[Gene Heskett]

On Saturday 18 July 2015 02:41:44 Felix Miata wrote:
> Gene Heskett composed on 2015-07-18 01:51 (UTC-0400):
> > Felix Miata wrote:
> >> What, if any, video parameters do you have on your kernel cmdline?
>
> ???
>
> ...
>
> > This isn't TCC, but the XFCE used for a linuxcnc install on those
> > machines.  Its debian wheezy, 7.8, with a real time patched kernel.
> >
> > TCC has no such choices here on this machine, but since it works
> > reasonably well on this dell 16x9 23"er, I haven't looked that hard
> > either.
> >
> > I have looked at xrandr, but see no controls that would effect that.
>
> I don't know about controls. I just put
>
>   http://fm.no-ip.com/Share/setup
>
> where it will get run when X starts, with whatever mode I want used
> uncommented. It works as expected on Jessie with TDE.
>
> Or, use
>
>   http://fm.no-ip.com/Share/Linux/xorg.conf-minimal-EDID-workaround
>
> or one of the others in that directory as a skeleton to create an
> xorg.conf file, uncommenting or creating the appropriate PreferredMode
> line. I don't recall trying this on Jessie, but it works in
> Kubuntu/TDE,
> Linuxmint/Cinnamon, Mageia/KDE4 (with kscreen disabled), Fedora/KDE4&5
> (with kscreen disabled) and openSUSE/KDE4&5 (with kscreen disabled).
>
> > The default seems to be 1280x768.
>
> I don't recall running across that one before. 16:9 @768 is 136X.
>
> > There is a 13nnx800 mode but the
> > images are bigger than the screen and circles are still smunched
> > vertically. 17" AOC monitor on the machine doing the squashing.
>
> A quick search for 17" AOC 16:9 suggests it should most likely be
> preferred/native 1600x900. What modes are listed by xrandr and/or
> Xorg.0.log?

Xorg.0.log is in my other reply, Felix.  I'm just up, need a quart of 
coffee I haven't made yet to function correctly. :-\

In any event, the machines in question do not have either 
an /etc/X11/xorg.conf, nor an /etc/X11/xorg.conf.d

Here is what is there:
gene@shop:/var/log$ cd /etc/X11
gene@shop:/etc/X11$ ls -l
total 72
drwxr-xr-x 2 root root  4096 Jul 16 08:35 app-defaults
-rw-r--r-- 1 root root18 Nov  5  2014 default-display-manager
drwxr-xr-x 6 root root  4096 May 18 12:11 fonts
-rw-r--r-- 1 root root 17394 Sep 29  2009 rgb.txt
lrwxrwxrwx 1 root root13 May 18 12:11 X -> /usr/bin/Xorg
drwxr-xr-x 2 root root  4096 May 18 12:11 xinit
drwxr-xr-x 2 root root  4096 Dec 25  2012 xkb
-rwxr-xr-x 1 root root   709 Oct 13  2010 Xreset
drwxr-xr-x 2 root root  4096 May 18 12:11 Xreset.d
drwxr-xr-x 2 root root  4096 May 18 12:11 Xresources
-rwxr-xr-x 1 root root  3517 Apr  8  2009 Xsession
drwxr-xr-x 2 root root  4096 May 18 13:52 Xsession.d
-rw-r--r-- 1 root root   265 Jan 15  2009 Xsession.options
-rw-r--r-- 1 root root13 May 24  2013 XvMCConfig
-rw-r--r-- 1 root root   601 Nov  5  2014 Xwrapper.config

Sort of off-topic, but this is the real world out here.

These installs are mostly debian wheezy (7.8) based and use the wheezy 
repo's for updates, but the install iso came from linuxcnc.org, is 
latest version.  The kernel is a special RTAI patched version & pinned 
so the update-manager doesn't muck with it. Linuxcnc will not run except 
in simulation mode w/o that kernel. Currently 3.4-9-rtai-686-pae, but 
the pae does not work.  The RTAI patches are VERY invasive.

I have the same situation with a machine I am attempting to make run a 
newer, bigger mill I am just now brining to life, but it doesn't have 
enough memory at 384 megs, and is a bit short of cpu as its a 1Ghz 
Athlon.  An HP Pavilion darned near old enough to vote, with an ATI 
video card running a 26" Samsung tv with a failed tuner as a monitor. 
TBR when a PSU for a Tyan S2721 gets here.  But that one I'll leave 
running in cold weather as supplemental heat in my well insulated 
garage.  The S2721 is a dual cpu monster server board.

Yet TBD is if isolcpus=1 will work, which leaves linuxcnc the total run 
of one core, improving its IRQ performance quite a bit if doing software 
stepping on stepper motors.  But I've a hardware card for that, so the 1 
millisecond "servo" thread is the main thread on machines with the 
hardware card in them.

NVidia drivers, FWTW, can even screw that up with their hundreds of 
milliseconds IRQ disabling.  So they get kicked into the next drainage, 
the curb isn't nearly far enough.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: intel atom D525MW w/i915 onboard gfx vs 16x9 monitor

[Gene Heskett]

On Saturday 18 July 2015 02:33:22 Thomas Lübking wrote:
> On Samstag, 18. Juli 2015 07:51:41 CEST, Gene Heskett wrote:
> > The default seems to be 1280x768.  There is a 13nnx800 mode but the
> > images are bigger than the screen and circles are still smunched
> > vertically. 17" AOC monitor on the machine doing the squashing.
>
> What are complete output of "xrandr -q", contents of
> /var/log/Xorg.0.log and the exact monitor model?
>
> Usually the system asks monitor and IGP for supported modes and
> presents you the intersection - 1280x768 is 16:9.6, but if the
> monitors physical pixels aren't square, this can end up as 16:9
>
> Cheers,
> Thomas

Board is Intel Atom D525MW

gene@shop:~$ xrandr -q
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 
509mm x 286mm
   1920x1080  60.0*+
   1280x1024  75.0 60.0  
   1152x864   75.0  
   1024x768   75.1 60.0  
   800x60075.0 60.3  
   640x48075.0 60.0  
   720x40070.1  
HDMI-1 disconnected (normal left inverted right x axis y axis)
VGA-1 disconnected (normal left inverted right x axis y axis)

Log:(word wrap off)
gene@shop:/var/log$ cat Xorg.0.log
[27.246] 
X.Org X Server 1.12.4
Release Date: 2012-08-27
[27.246] X Protocol Version 11, Revision 0
[27.246] Build Operating System: Linux 3.2.0-4-amd64 i686 Debian
[27.246] Current Operating System: Linux shop 3.4-9-rtai-686-pae #1 SMP 
PREEMPT Debian 3.4.55-4linuxcnc i686
[27.246] Kernel command line: BOOT_IMAGE=/vmlinuz-3.4-9-rtai-686-pae 
root=UUID=ef74047c-6f7e-4e27-93f3-917d36ca8b2c ro 
initrd=/install/gtk/initrd.gz lapic isolcpus=1 rootdelay=5
[27.246] Build Date: 09 February 2015  10:12:47AM
[27.246] xorg-server 2:1.12.4-6+deb7u6 (Julien Cristau 
) 
[27.247] Current version of pixman: 0.26.0
[27.247]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[27.247] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[27.247] (==) Log file: "/var/log/Xorg.0.log", Time: Thu May 28 14:27:22 
2015
[27.276] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[27.318] (==) No Layout section.  Using the first Screen section.
[27.318] (==) No screen section available. Using defaults.
[27.318] (**) |-->Screen "Default Screen Section" (0)
[27.318] (**) |   |-->Monitor ""
[27.319] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[27.319] (==) Automatically adding devices
[27.319] (==) Automatically enabling devices
[27.354] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[27.354]Entry deleted from font path.
[27.358] (WW) The directory 
"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist.
[27.358]Entry deleted from font path.
[27.358] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[27.358] (==) ModulePath set to "/usr/lib/xorg/modules"
[27.358] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[27.358] (II) Loader magic: 0xb77ea5a0
[27.358] (II) Module ABI versions:
[27.358]X.Org ANSI C Emulation: 0.4
[27.358]X.Org Video Driver: 12.1
[27.358]X.Org XInput driver : 16.0
[27.358]X.Org Server Extension : 6.0
[27.360] (--) PCI:*(0:0:2:0) 8086:a001:8086:574d rev 2, Mem @ 
0xf030/524288, 0xe000/268435456, 0xf020/1048576, I/O 
@ 0x20c0/8
[27.360] (II) Open ACPI successful (/var/run/acpid.socket)
[27.360] (II) LoadModule: "extmod"
[27.363] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[27.377] (II) Module extmod: vendor="X.Org Foundation"
[27.377]compiled for 1.12.4, module version = 1.0.0
[27.377]Module class: X.Org Server Extension
[27.377]ABI class: X.Org Server Extension, version 6.0
[27.378] (II) Loading extension SELinux
[27.378] (II) Loading extension MIT-SCREEN-SAVER
[27.378] (II) Loading extension XFree86-VidModeExtension
[27.378] (II) Loading extension XFree86-DGA
[27.378] (II) Loading extension DPMS
[27.378] (II) Loading extension XVideo
[27.378] (II) Loading extension XVideo-MotionCompensation
[27.378] (II) 

Re: intel atom D525MW w/i915 onboard gfx vs 16x9 monitor

[Gene Heskett]

On Saturday 18 July 2015 01:20:35 Felix Miata wrote:
> Gene Heskett composed on 2015-07-18 00:06 (UTC-0400):
> > Does anyone know how to get a square pixel on this gfx set?
> >
> > It works well on a 4x3 monitor, but circles are squashed on a 16x9.
>
> What, if any, video parameters do you have on your kernel cmdline? One
> can act as a signal to prevent automagic X configuration from working
> with the Xorg Intel driver, which wants to use it instead of EDID
> preferred unless you use some kind of X config to override it, either
> the traditional route of xrandr commands on startup or
> /etc/X11/xorg.conf*, or xrandr commands hidden in the DE's desktop
> settings for the display, if applicable. As I always go the
> traditional route, I've no expectations whether Trinity's Control
> Center Display Size & Orientation work as expected, but I should think
> they would, same as counterparts in KDE or other DEs.

This isn't TCC, but the XFCE used for a linuxcnc install on those 
machines.  Its debian wheezy, 7.8, with a real time patched kernel.

TCC has no such choices here on this machine, but since it works 
reasonably well on this dell 16x9 23"er, I haven't looked that hard 
either.

I have looked at xrandr, but see no controls that would effect that.

> TCC does work 
> here on a P4D/G33 installation on a 16:10 display to switch between
> 1600x1200 and 1440x900. AFAIK, Intel on the Atom in this regard acts
> no differently than it does on any other x86.

The default seems to be 1280x768.  There is a 13nnx800 mode but the 
images are bigger than the screen and circles are still smunched 
vertically. 17" AOC monitor on the machine doing the squashing.

Thanks Felix.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

intel atom D525MW w/i915 onboard gfx vs 16x9 monitor

[Gene Heskett]

Greetings all;

Does anyone know how to get a square pixel on this gfx set?

It works well on a 4x3 monitor, but circles are squashed on a 16x9.

Thank You.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: xserver-xorg.synaptics question

[Gene Heskett]

On Wednesday 29 April 2015 06:21:43 Gene Heskett wrote:
> On Wednesday 29 April 2015 05:37:00 Thomas Lübking wrote:
> > On Mittwoch, 29. April 2015 02:51:04 CEST, Gene Heskett wrote:
> > > Now, where is the last script that X executes as it completes it
> > > initialization?
> >
> > This depends on you DM (xdm, kdm, ldm, gdm, sddm, ...) resp. the
> > desktop environment (eg. some source ~/.xprofile, but there's really
> > no guarantee)
> >
> > For LXDE, ~/.config/lxsession/LXDE/autostart should work, see
> > https://wiki.archlinux.org/index.php/LXDE#Autostart
>
> For Lubuntu 14.4-2 LTS it appears to be:
> ~/.config/lxsession/Lununtu/autostart
s/b ~/.config/lxsession/Lubuntu/autostart

Friggin fingers don't always type what I tell them to...

> Which /was/ an empty file.  And it worked.  It was disabled about 6 or
> 7 seconds after I logged in on a reboot.
>
> Thank you very much Thomas.
>
> > Cheers,
> > Thomas
> > ___
> > xorg@lists.x.org: X.Org support
> > Archives: http://lists.freedesktop.org/archives/xorg
> > Info: http://lists.x.org/mailman/listinfo/xorg
> > Your subscription address: %(user_address)s
>
> Cheers, Gene Heskett

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: xserver-xorg.synaptics question

[Gene Heskett]

On Wednesday 29 April 2015 05:37:00 Thomas Lübking wrote:
> On Mittwoch, 29. April 2015 02:51:04 CEST, Gene Heskett wrote:
> > Now, where is the last script that X executes as it completes it
> > initialization?
>
> This depends on you DM (xdm, kdm, ldm, gdm, sddm, ...) resp. the
> desktop environment (eg. some source ~/.xprofile, but there's really
> no guarantee)
>
> For LXDE, ~/.config/lxsession/LXDE/autostart should work, see
> https://wiki.archlinux.org/index.php/LXDE#Autostart

For Lubuntu 14.4-2 LTS it appears to be:
~/config/lxsession/Lununtu/autostart

Which /was/ an empty file.  And it worked.  It was disabled about 6 or 7 
seconds after I logged in on a reboot.

Thank you very much Thomas.

> Cheers,
> Thomas
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: xserver-xorg.synaptics question

[Gene Heskett]

On Tuesday 28 April 2015 16:21:12 Thomas Lübking wrote:
> On Dienstag, 28. April 2015 19:16:17 CEST, Gene Heskett wrote:
> > You missed the point Thomas.  I have a mouse. I want that touchpad
> > totally and absolutely nuked
>
> Try
> synclient TouchpadOff=1

This works well to kill the pad itself, but not its external buttons, and 
I don't see that option in the extensive help output from synclient -l.  
This I suspect will do it since the buttons do need a conscious push.  
The touchpad responds to me thumbing my nose at it from 3 feet, or at 
least does a great job of convincing me that it can. :(


Now, where is the last script that X executes as it completes it 
initialization? 

Seems like that would be the obvious place to add the above line.
[...]
>
> > But its moot. I am now trying to get lubuntu 14.04-2 LTS to start
> > the

Which I have now done.

> I don't think things are gonna change because you switch to
> yet-another-ubuntu-derivate ;-)

In this case, and unrelated to it, lubuntu has so far stood above all the 
others, head, shoulders, and belly button above the crowd. Many things I 
battled with on Mint 17.1, are now Just Working.  Except nfs.  But thats 
another post & thread for tomorrow.

Thank you Thomas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: xserver-xorg.synaptics question

[Gene Heskett]

On Tuesday 28 April 2015 13:45:47 Felix Miata wrote:
> Gene Heskett composed on 2015-04-28 13:16 (UTC-0400):
> > I am now trying to get lubuntu 14.04-2 LTS to start the
> > install, but its stuck looking for a network connection it will
> > never find because there is not a dhcpd running anyplace on my local
> > network, which isn't in the 192.168.1 block.  And no way to nuke
> > network-mangler long enough to edit and commit the correct network
> > configs to make it Just Work(TM)
>
> Do a network installation and include netcfg/disable_dhcp=true on its
> cmdline. It's how I do all "debian" installations on my own systems. I
> suppose the same parameter should have same effect on non-network
> installations.

I am amazed, dumbfounded, totally blown away Felix.

Someone has been working on the code behind the network icon on the task 
bar, and I was able to setup a one machine network using it that  
actually worked!

So the install is proceeding apace.  But touchpad is alive yet. :(
I've no idea how fast, but the install gui has more color depth than 
Mints did when booted to it after the install.  This old machine could 
even look decent if I got froggy, and opened the screen & replaced its 
leds with 10x brighter ones.  Since I am a CET, I'd imagine that would 
not be beyond my pay grade.  Unfortunately, the 80 years on the wet ram 
are showing in my short term memory.

Thanks Felix.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: xserver-xorg.synaptics question

[Gene Heskett]

On Tuesday 28 April 2015 10:39:04 Thomas Lübking wrote:
> On Dienstag, 28. April 2015 12:47:21 CEST, Gene Heskett wrote:
> > Can you kind folks recommend a distribution with a lightweight gui
> > that actually works?, or do I have to open this 12 year old puny
> > powered lappy up and physically disconnect the touchpad?
>
> I missed most of the thread and dunno why Mint nukes config paths, but
> you can probably use synclient to adjust the touchpad at runtime (in
> doubt from some login script)
>
> synclient FingerLow=35
> synclient FingerHigh=40
>
> play with the values until it's nice for you. Keep Low below High.
>
> There's also
> synclient PalmDetect=1
>
> for the clumsy among us =)
>
> Cheers,
> Thomas

You missed the point Thomas.  I have a mouse. I want that touchpad 
totally and absolutely nuked, as if it is just an odd colored piece of 
plastic in the panel that does absolutely nothing.

This particular version of the pad control, called tpconfig I think, is 
so confused that disabling the touchpad tabs scrolling also disables the 
mouse wheel.

But its moot. I am now trying to get lubuntu 14.04-2 LTS to start the 
install, but its stuck looking for a network connection it will never 
find because there is not a dhcpd running anyplace on my local network, 
which isn't in the 192.168.1 block.  And no way to nuke network-mangler 
long enough to edit and commit the correct network configs to make it 
Just Work(TM)

I am out of patience with that network destroyer.  If I could reach into 
the dvd and burn out the space occupied by it, I would in a millisecond.

Thanks for the reply Thomas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: xserver-xorg.synaptics question

[Gene Heskett]

On Tuesday 28 April 2015 06:38:53 Eric Gunther wrote:
> > Mint 17.1 Xfce.  I had to make that directory, and moved it to
> > 50-synaptics.conf in that otherwise empty, newly created dir. 
> > Rebooted now, I'll check.  Nope, not a noticeable difference.  Copy
> > of Xorg.0.log attached.
>
> Hi Gene,
>
> Shouldn't you just decrease the sensitivity in xfce settings:
> http://docs.xfce.org/xfce/xfce4-settings/mouse

My control panel>mouse>touchpad_tab config has only a disable tp when 
typing, and scrolling choices none, both of which are checked.
It doesn't resemble that one above other than its a popup too.

Having wasted about 3 weeks trying to get this as usable as a 12 yo 
Mandrake install was OOTB, I am ready to move on.  The only thing I have 
managed to make work that did not after the install reboot networking 
and NFS4.

I set t-bird up to one on my accounts and exersized it to prove it works 
and shut off the periodical mail fetch since this machine does it if its 
up.  An hour later, I come back to the machine and find its scarfed up 
300+ messages that should have come to this machine, and it did it 
despite being told to stop.

The synaptic package manager has been castrated by the removal of 
the "mark all upgrades" button.  I mean whoinhell is gonna scan thru the 
listing of 46 thousand packages, finding the ones that are upgradeable 
according the the green installed icon having a faint up arrow in it, 
and enable THAT individual package to be upgraded by dbl clicking, not 
on the icon mind you, but someplace in the descriptive text.  Get real 
folks, you cannot be expected to do that to all 1700 some packages 
needing updated after the install.  But I did just that anyway.

So many of what some people might call little things are broken in this 
mint 17.1 xfce install that I am going out to see if I can find a distro 
that Just Works.  Something that is lightweight enough to work on an 
elderly laptop.  I do not consider that 15 to 30 seconds to open an app 
after its clicked on, running.  The drive led is on for 90% of this lag 
period.  Its 100Gb drive tests perfectly.  It only has a gig of memory, 
but hasn't touched swap yet.

This one, Mint-17.1 xfce ain't it.

> -eg
>
Thanks Eric.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: xserver-xorg.synaptics question

[Gene Heskett]

On Tuesday 28 April 2015 02:53:28 Peter Hutterer wrote:
> On Tue, Apr 28, 2015 at 12:02:56AM -0400, Gene Heskett wrote:
> > On Monday 27 April 2015 23:53:00 Felix Miata wrote:
> > > Gene Heskett composed on 2015-04-27 23:10 (UTC-0400):
> > > > Mint 17.1 Xfce.  I had to make that directory, and moved it to
> > > > 50-synaptics.conf in that otherwise empty, newly created dir.
> > > > Rebooted now, I'll check.  Nope, not a noticeable difference. 
> > > > Copy of Xorg.0.log attached.
> > > >
> > > > As of the last reboot, correspnding to the Xorg.0.log attached,
> > > > there is no /etc/X11/xorg.conf file.
> > > >
> > > > May be you can see something in the logfile I cannot?
> > >
> > > Nothing I recognize. Something else you can try is putting a file
> > > of whatever name you please in $HOME, then export
> > > 'XORGCONFIG=whatever' in .bashrc. If that doesn't work either,
> > > maybe there's a bug or the ignore option for synaptics has been
> > > removed. Or, maybe Mint is using the libinput driver instead of
> > > the synaptics driver and there's a whole different methodology
> > > required to disable it.
> >
> > Sound like I ought to head back over to their list & see if I can
> > synthesize some hate & discontent.  They have been nice, but also
> > less than helpfull on this front.
> >
> > I'll give this a shot too, but from what I see in the startup log
> > for x, it isn't looking at anything I have done so far, so I don't
> > have any great hopes that the above might work.  Sigh.
>
> from your log:
> [39.796] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Apr 27
> 22:54:01 2015
> [39.851] (==) Using system config directory
> "/usr/share/X11/xorg.conf.d"
>
> from my log:
> [370012.609] (==) Log file: "/var/log/Xorg.1.log", Time: Tue Apr 28
> 13:09:52 2015
> [370012.610] (==) Using config directory: "/etc/X11/xorg.conf.d"
> [370012.610] (==) Using system config directory
> "/usr/share/X11/xorg.conf.d"
>
> Check your/mint's configure options. This is rather odd.

Odd? I'll nominate that for understatement of the month.

I have now read everything in  /etc/X11, and everything in /usr/share/X11 
to no avail.  Without finding a clue as to which of these directories 
that LOOK like the configuration directories is used. Nothing I can edit 
into 50-synaptics.conf, no matter where I find it, does a thing. I just 
commented out the whole touchpad stanza in evdev too.  Zero effect.  It, 
and its buttons still work after the reboot.

My patience runneth out.

I am tired, sick to death of its focus stealing, or highlighting the 
whole message as I type, to have the whole damned message disappeaar 
before I can stop my fingers from typing the next character.  I want it 
100% gone. Effectively an empty hole in the lappies panel.

Can you kind folks recommend a distribution with a lightweight gui that 
actually works?, or do I have to open this 12 year old puny powered 
lappy up and physically disconnect the touchpad?

> Cheers,
>Peter

Thanks Peter.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: xserver-xorg.synaptics question

[Gene Heskett]

On Monday 27 April 2015 23:53:00 Felix Miata wrote:
> Gene Heskett composed on 2015-04-27 23:10 (UTC-0400):
> > Mint 17.1 Xfce.  I had to make that directory, and moved it to
> > 50-synaptics.conf in that otherwise empty, newly created dir. 
> > Rebooted now, I'll check.  Nope, not a noticeable difference.  Copy
> > of Xorg.0.log attached.
> >
> > As of the last reboot, correspnding to the Xorg.0.log attached,
> > there is no /etc/X11/xorg.conf file.
> >
> > May be you can see something in the logfile I cannot?
>
> Nothing I recognize. Something else you can try is putting a file of
> whatever name you please in $HOME, then export 'XORGCONFIG=whatever'
> in .bashrc. If that doesn't work either, maybe there's a bug or the
> ignore option for synaptics has been removed. Or, maybe Mint is using
> the libinput driver instead of the synaptics driver and there's a
> whole different methodology required to disable it.

Sound like I ought to head back over to their list & see if I can 
synthesize some hate & discontent.  They have been nice, but also less 
than helpfull on this front.

I'll give this a shot too, but from what I see in the startup log for x, 
it isn't looking at anything I have done so far, so I don't have any 
great hopes that the above might work.  Sigh.

Thanks Felix.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: xserver-xorg.synaptics question

[Gene Heskett]

On Monday 27 April 2015 22:02:42 Felix Miata wrote:
> Gene Heskett composed on 2015-04-27 21:24 (UTC-0400):
> >> > Can someone tell me how to edit the
> >> > /usr/share/X11/50-synaptics.conf file, which when copied to
> >> > /etc/X11/xorg.conf, will disable it totally?
> >>
> >> what exactly do you want to do? ignore the device completely?
> >>
> >> Section "InputClass"
> >>Identifier "ignore touchpads"
> >>MatchDriver "synaptics"
> >>Option "Ignore" "on"
> >> EndSection
> >
> > I put that into the file, then renamed it to Xorg.conf when that
> > didn't work, followed by another reboot, no difference in the
> > behaviour or the Xorg.0.log.
> >
> > Does it belong in the Xsessions.d subdir?
>
> /etc/X11/Xsession.d/ is for scripts to be executed, not .conf files.
>
> /etc/X11/xorg.conf.d/
>
Mint 17.1 Xfce.  I had to make that directory, and moved it to 
50-synaptics.conf in that otherwise empty, newly created dir.  Rebooted 
now, I'll check.  Nope, not a noticeable difference.  Copy of Xorg.0.log 
attached.

> > And what is its correct name?
>
> Name isn't crucial if in /etc/X11/xorg.conf.d/. 50-synaptics.conf
> should be fine. 05-input.conf should do just as well.
> /etc/X11/xorg.conf should work too, but you don't want overlap between
> /etc/X11/xorg.conf
> /etc/X11/xorg.conf.d/* trying to control the same device - you might
> wind up with everything being ignored.
As of the last reboot, correspnding to the Xorg.0.log attached, there is 
no /etc/X11/xorg.conf file.

May be you can see something in the logfile I cannot?

Thanks Felix.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
[39.795] 
X.Org X Server 1.15.1
Release Date: 2014-04-13
[39.795] X Protocol Version 11, Revision 0
[39.795] Build Operating System: Linux 3.2.0-76-generic x86_64 Ubuntu
[39.795] Current Operating System: Linux lappy 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64
[39.795] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.13.0-37-generic root=UUID=220a8742-1e8e-4de9-8cee-8b4dc2e6b677 ro quiet splash vt.handoff=7
[39.796] Build Date: 12 February 2015  02:49:29PM
[39.796] xorg-server 2:1.15.1-0ubuntu2.7 (For technical support please see http://www.ubuntu.com/support) 
[39.796] Current version of pixman: 0.30.2
[39.796] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[39.796] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[39.796] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Apr 27 22:54:01 2015
[39.851] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[39.852] (==) No Layout section.  Using the first Screen section.
[39.852] (==) No screen section available. Using defaults.
[39.852] (**) |-->Screen "Default Screen Section" (0)
[39.852] (**) |   |-->Monitor ""
[39.852] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
[39.852] (==) Automatically adding devices
[39.852] (==) Automatically enabling devices
[39.852] (==) Automatically adding GPU devices
[39.852] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[39.852] 	Entry deleted from font path.
[39.852] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[39.852] 	Entry deleted from font path.
[39.852] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[39.852] 	Entry deleted from font path.
[39.852] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[39.852] 	Entry deleted from font path.
[39.852] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[39.852] 	Entry deleted from font path.
[39.852] (==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/Type1,
	built-ins
[39.852] (==) ModulePath set to "/usr/lib/x86_64-linux-gnu/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
[39.852] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[39.852] (II) Loader magic: 0x7f8292914d40
[39.853] (II) Module ABI versions:
[39.853] 	X.Org ANSI C Emulation: 0.4
[39.853] 	X.Org Video Driver: 15.0
[39.853

Re: xserver-xorg.synaptics question

[Gene Heskett]

On Monday 27 April 2015 22:29:11 Peter Hutterer wrote:
> On Mon, Apr 27, 2015 at 09:24:37PM -0400, Gene Heskett wrote:
> > On Monday 27 April 2015 20:17:57 Peter Hutterer wrote:
> > > On Mon, Apr 27, 2015 at 07:15:05PM -0400, Gene Heskett wrote:
> > > > Greetings all;
> > > >
> > > > Can someone tell me how to edit the
> > > > /usr/share/X11/50-synaptics.conf file, which when copied to
> > > > /etc/X11/xorg.conf, will disable it totally?
> > >
> > > what exactly do you want to do? ignore the device completely?
> > >
> > > Section "InputClass"
> > >Identifier "ignore touchpads"
> > >MatchDriver "synaptics"
> > >Option "Ignore" "on"
> > > EndSection
> >
> > I put that into the file, then renamed it to Xorg.conf when that
> > didn't work, followed by another reboot, no difference in the
> > behaviour or the Xorg.0.log.
> >
> > Does it belong in the Xsessions.d subdir?
> >
> > And what is its correct name?
>
> put it in /etc/X11/xorg.conf.d/99-ignore-synaptics.conf

I was going to, but the /etc/X11/xorg.conf.d directory I just made,  put 
the file in there as 50-synaptics.conf before I rebooted, but it appears 
X blows that directory away during the boot.  It and the file are gone 
after the reboot.

Is it beer-thirty yet? :(

> Cheers,
>Peter

Thanks Peter.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: xserver-xorg.synaptics question

[Gene Heskett]

On Monday 27 April 2015 20:17:57 Peter Hutterer wrote:
> On Mon, Apr 27, 2015 at 07:15:05PM -0400, Gene Heskett wrote:
> > Greetings all;
> >
> > Can someone tell me how to edit the /usr/share/X11/50-synaptics.conf
> > file, which when copied to /etc/X11/xorg.conf, will disable it
> > totally?
>
> what exactly do you want to do? ignore the device completely?
>
> Section "InputClass"
>Identifier "ignore touchpads"
>MatchDriver "synaptics"
>Option "Ignore" "on"
> EndSection
>
I put that into the file, then renamed it to Xorg.conf when that didn't 
work, followed by another reboot, no difference in the behaviour or the 
Xorg.0.log.

Does it belong in the Xsessions.d subdir?  

And what is its correct name?

Thanks Peter.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

xserver-xorg.synaptics question

[Gene Heskett]

Greetings all;

Can someone tell me how to edit the /usr/share/X11/50-synaptics.conf 
file, which when copied to /etc/X11/xorg.conf, will disable it totally?
That thing is so sensitive it can cause a focus grab away from what you 
are trying to do while the nearest part of a hovering over it hand is 
still an inch or more away from actually touching it.

It is a major pita on my old HP dv5120us laptop, when I have to go grab 
the mouse, find it on screen, and then reclick on the terminal screen I 
am using before I can type another character.

Hints please.

Thank you.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [ANNOUNCE] libXdmcp 1.1.2

[Gene Heskett]

On Saturday 21 March 2015 13:05:16 Alan Coopersmith wrote:
> libXdmcp is the X Display Manager Control Protocol library, used by
> both X servers and display managers to handle both ends of the XDMCP
> connection.
>
> This release has hardened handling of invalid arguments & allocation
> failures, adds support for using arc4random in key generation, and
> adds some unit tests to help developers prevent regressions in the
> future.

Alan: Can replace the deb package in wheezy, which is 1.1.1-1, with this 
without any excitement?  3.4-9AMD64 kernel running ATM.

Thanks.

> Alan Coopersmith (11):
>   Remove unused TLI ("STREAMSCONN") code from libXdmcp
>   Ensure ARRAY* structs are zero'ed out when allocation fails
>   Make XdmcpCopyARRAY8 call XdmcpAllocARRAY8 instead of
> replicating it Add unit tests for Array allocation functions
>   Ensure ARRAY* structs are zero'ed out when oversize values are
> passed Ensure ARRAYofARRAY8 pointers are initialized to NULL
>   Also reject requests to allocate negative sized amounts of
> memory configure: Drop AM_MAINTAINER_MODE
>   autogen.sh: Honor NOCONFIGURE=1
>   Add AC_USE_SYSTEM_EXTENSIONS to expose arc4random() interfaces
> in headers libXdmcp 1.1.2
>
> Matthieu Herrb (1):
>   Use arc4random when available to produce the XDM-AUTHENTICATION1
> key
>
> git tag: libXdmcp-1.1.2
>
> http://xorg.freedesktop.org/archive/individual/lib/libXdmcp-1.1.2.tar.
>bz2 MD5:  18aa5c1279b01f9d18e3299969665b2e
> SHA1: 3c09eabb0617c275b5ab09fae021d279a4832cac
> SHA256:
> 81fe09867918fff258296e1e1e159f0dc639cb30d201c53519f25ab73af4e4e2 PGP: 
> http://xorg.freedesktop.org/archive/individual/lib/libXdmcp-1.1.2.tar.
>bz2.sig
>
> http://xorg.freedesktop.org/archive/individual/lib/libXdmcp-1.1.2.tar.
>gz MD5:  ab0d6a38f0344a05d698ec7d48cfa5a8
> SHA1: 486a7fea7c7e43df0b9032ae23f592420728ad52
> SHA256:
> 6f7c7e491a23035a26284d247779174dedc67e34e93cc3548b648ffdb6fc57c0 PGP: 
> http://xorg.freedesktop.org/archive/individual/lib/libXdmcp-1.1.2.tar.
>gz.sig

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Still more Q on nouveau driver & version missmatch

[Gene Heskett]

Greetings;

Back again...

Running  linux-3.16.0, home built.  Using the nouveau driver on an
EVGA GeForce 8400 GS card
Messages log being spammed hundreds of megabytes a week by something 
nouveau version in kernel vs version of x installed related.  X is from
the server version of 10.04.4 LTS with enough x & kde installed to get
a window manager and kmail working.

My audio & video is stuttering something terrible about 98% of the time, 
on a quad core phenom with 8Gb of ram.

Something was said about the frame buffer being incompatible, and I asked 
where could I dl the newer x so I could build it here, and was not answered.

Now this morning I find that I do have a module nvidiafb.ko:

gene@coyote:/etc$ ls -l 
/lib/modules/3.16.0/kernel/drivers/video/fbdev/nvidia/nvidiafb.ko
-rw-r--r-- 1 root root 48412 2014-12-05 12:36 
/lib/modules/3.16.0/kernel/drivers/video/fbdev/nvidia/nvidiafb.ko

But:

gene@coyote:/etc$ sudo modprobe 
/lib/modules/3.16.0/kernel/drivers/video/fbdev/nvidia/nvidiafb.ko
FATAL: Module /lib/modules/3.16.0/kernel/drivers/video/fbdev/nvidia/nvidiafb.ko 
not found.

So my question is, why this module can't even be found when I give 
modprobe the full path to it?

Attempting to insmod it, I get an unknown symbol in module error return.

How can I alleviate this audio & video pain?

Thanks & Merry Christmas to all.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Need help with M$ touchmouse

[Gene Heskett]

On Saturday 06 December 2014 15:09:31 Thomas Lübking did opine
And Gene did reply:
> On Samstag, 6. Dezember 2014 03:21:10 CEST, Gene Heskett wrote:
> > Is it on git, or do I have to dl a tarball?
> 
> Either. [1][2]
> The problem rather is that you'll *have* to compile several packages
> and very much likely also need to update some build tools as well.
> 
> > Other than the fact that even the LinuxCNC simulator would probably
> > die
> 
> Sorry, I don't follow here. What do you mean by "die"?
> You mean http://linuxcnc.org/ ?
> I'd rather try to build that from sources (seems to be mostly python &
> tcl/tk anyway) on a parallel installation of an up-to-date distro of
> your choice.
> 
> Cheers,
> Thomas
> 
> 
> [1] http://ftp.x.org/pub/individual/, for mirrors:
> http://www.x.org/wiki/Releases/Download/ [2]
> http://cgit.freedesktop.org/, see "Xorg" repos.

Great Thomas, marked msg important. ATM am in a swamp full of alligators 
in some gcode.  and I can't find the drain plug.

Clearly, I have too many hobbies.  But they collaborate to keep me out of 
the bars too. ;)

> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Need help with M$ touchmouse

[Gene Heskett]

On Saturday 06 December 2014 14:27:34 Alan Coopersmith did opine
And Gene did reply:
> On 12/ 5/14 10:31 AM, Gene Heskett wrote:
> > And it is still unloading the nv driver, which I_thought_  was the
> > nvidia driver.
> 
> "nv" is the old open source xf86-video-nv driver, which nvidia used to
> provide updates to, but just enough to get the system up and running
> to install their closed source "nvidia" driver.   They've stopped that
> and now recommend the vesa driver for such bootstrapping instead.
> 
> "nouveau" is the current open source driver for nvidia chipsets, if you
> have the required nouveau kernel driver available for it.

Yes, but no one (I've not looked all that hard though) has given me a url 
where I might be able to pull a fresher Xorg install from.  Tarball or 
deb, tarball probably better because configure would check and make me 
update what it needs.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Need help with M$ touchmouse

[Gene Heskett]

On Saturday 06 December 2014 06:14:12 Peter Hutterer did opine
And Gene did reply:
> On 6/12/2014 12:33 , Gene Heskett wrote:
> > On Friday 05 December 2014 18:46:58 Peter Hutterer did opine
> > 
> > And Gene did reply:
> >> On 6/12/2014 01:56 , Gene Heskett wrote:
> >>> On Thursday 04 December 2014 23:03:38 Peter Hutterer did opine
> >>> 
> >>> And Gene did reply:
> >>>> On Thu, Dec 04, 2014 at 09:43:44PM -0500, Gene Heskett wrote:
> >>>>> On Thursday 04 December 2014 16:18:16 Peter Hutterer did opine
> >>>>> 
> >>>>> And Gene did reply:
> >>>>>> On Thu, Dec 04, 2014 at 01:23:49PM -0500, Gene Heskett wrote:
> >>>>>>> Greetings all;
> >>>>>>> 
> >>>>>>> I have a wireless M$ Explorer Touchmouse, and the touch pad is
> >>>>>>> buggier than a 10 day old carcass.
> >>>>>>> 
> >>>>>>> Specifically, the side scrolling is driving me crazy, and its
> >>>>>>> not a long trip. ;)
> >>>>>>> 
> >>>>>>> When it works, its 20x more sensitive sideways than vertically,
> >>>>>>> and I can't get my fingers far enough away from the pad to stop
> >>>>>>> its crazy behavior, and still rest them in a comfy location for
> >>>>>>> button pushing.
> >>>>>>> 
> >>>>>>> Is there anything I can put in an /etc/X11 file that will shut
> >>>>>>> the side scroll function off, but leave the vertical finger
> >>>>>>> drags working?
> >>>>>> 
> >>>>>> attach an evemu recording and your xorg.log to a bug please. I
> >>>>>> don't have a recording for this one yet so it's hard to tell.
> >>>>>> 
> >>>>>> Cheers,
> >>>>>> 
> >>>>>>  Peter
> >>>>> 
> >>>>> First off Peter, evemu is not 'locate'able.  And I'm not sure you
> >>>>> want the current Xorg.0.log in your mailbox as its north of 179
> >>>>> megabytes.
> >>>> 
> >>>> you could have restarted X, or started another session for a fresh
> >>>> log file. or cut down the thousands of lines of errors which is
> >>>> likely what 99% of the log file are if it grows to that size in a
> >>>> week.
> >>>> 
> >>>>> I even sicc'd synaptic to find it in the ubuntu repo, and came up
> >>>>> dry there too.
> >>>> 
> >>>> evemu shows up as second link on google for me:
> >>>> http://www.freedesktop.org/wiki/Evemu/
> >>>> 
> >>>> but tbh, if you're on a 4 year old box you're pretty much on your
> >>>> own, sorry. there may have been kernel fixes since, there may have
> >>>> been evdev fixes since, etc.
> >>> 
> >>> I do occsionally build a fresher kernel because the default kernel
> >>> for this particular install, an rtai kit on top of 2.6.32-123, has
> >>> no PAE and there's 8Gb in this box.  Running the OEM kernel only
> >>> sees 3Gb of that, and I'm a gigabyte into swap in 24hrs.
> >>> 
> >>> So the presently running kernel is a 3.16.0.  32 bit with PAE.
> >>> Hasn't touched swap in months.
> >>> 
> >>> Nest, that link 3rd line is bogus, needs an ".sh" tagged onto the
> >>> ./autogen script cli invocation.
> >>> 
> >>> The autogen output this to the screen:
> >>> gene@coyote:/usr/src/evemu$ ./autogen.sh --prefix=/usr
> >>> autoreconf: Entering directory `.'
> >>> autoreconf: configure.ac: not using Gettext
> >>> autoreconf: running: aclocal
> >>> autoreconf: configure.ac: tracing
> >>> autoreconf: configure.ac: creating directory config-aux
> >>> autoreconf: running: libtoolize --install --copy
> >>> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR,
> >>> `config-aux'. libtoolize: copying file `config-aux/config.guess'
> >>> libtoolize: copying file `config-aux/config.sub'
> >>> libtoolize: copying file `config-aux/install-sh'
> >>> libtoolize: copying file `config-aux/ltmain.sh'
> >>> libtoolize: Consider addin

Re: Need help with M$ touchmouse

[Gene Heskett]

On Friday 05 December 2014 18:46:58 Peter Hutterer did opine
And Gene did reply:
> On 6/12/2014 01:56 , Gene Heskett wrote:
> > On Thursday 04 December 2014 23:03:38 Peter Hutterer did opine
> > 
> > And Gene did reply:
> >> On Thu, Dec 04, 2014 at 09:43:44PM -0500, Gene Heskett wrote:
> >>> On Thursday 04 December 2014 16:18:16 Peter Hutterer did opine
> >>> 
> >>> And Gene did reply:
> >>>> On Thu, Dec 04, 2014 at 01:23:49PM -0500, Gene Heskett wrote:
> >>>>> Greetings all;
> >>>>> 
> >>>>> I have a wireless M$ Explorer Touchmouse, and the touch pad is
> >>>>> buggier than a 10 day old carcass.
> >>>>> 
> >>>>> Specifically, the side scrolling is driving me crazy, and its not
> >>>>> a long trip. ;)
> >>>>> 
> >>>>> When it works, its 20x more sensitive sideways than vertically,
> >>>>> and I can't get my fingers far enough away from the pad to stop
> >>>>> its crazy behavior, and still rest them in a comfy location for
> >>>>> button pushing.
> >>>>> 
> >>>>> Is there anything I can put in an /etc/X11 file that will shut
> >>>>> the side scroll function off, but leave the vertical finger
> >>>>> drags working?
> >>>> 
> >>>> attach an evemu recording and your xorg.log to a bug please. I
> >>>> don't have a recording for this one yet so it's hard to tell.
> >>>> 
> >>>> Cheers,
> >>>> 
> >>>> Peter
> >>> 
> >>> First off Peter, evemu is not 'locate'able.  And I'm not sure you
> >>> want the current Xorg.0.log in your mailbox as its north of 179
> >>> megabytes.
> >> 
> >> you could have restarted X, or started another session for a fresh
> >> log file. or cut down the thousands of lines of errors which is
> >> likely what 99% of the log file are if it grows to that size in a
> >> week.
> >> 
> >>> I even sicc'd synaptic to find it in the ubuntu repo, and came up
> >>> dry there too.
> >> 
> >> evemu shows up as second link on google for me:
> >> http://www.freedesktop.org/wiki/Evemu/
> >> 
> >> but tbh, if you're on a 4 year old box you're pretty much on your
> >> own, sorry. there may have been kernel fixes since, there may have
> >> been evdev fixes since, etc.
> > 
> > I do occsionally build a fresher kernel because the default kernel
> > for this particular install, an rtai kit on top of 2.6.32-123, has
> > no PAE and there's 8Gb in this box.  Running the OEM kernel only
> > sees 3Gb of that, and I'm a gigabyte into swap in 24hrs.
> > 
> > So the presently running kernel is a 3.16.0.  32 bit with PAE. 
> > Hasn't touched swap in months.
> > 
> > Nest, that link 3rd line is bogus, needs an ".sh" tagged onto the
> > ./autogen script cli invocation.
> > 
> > The autogen output this to the screen:
> > gene@coyote:/usr/src/evemu$ ./autogen.sh --prefix=/usr
> > autoreconf: Entering directory `.'
> > autoreconf: configure.ac: not using Gettext
> > autoreconf: running: aclocal
> > autoreconf: configure.ac: tracing
> > autoreconf: configure.ac: creating directory config-aux
> > autoreconf: running: libtoolize --install --copy
> > libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR,
> > `config-aux'. libtoolize: copying file `config-aux/config.guess'
> > libtoolize: copying file `config-aux/config.sub'
> > libtoolize: copying file `config-aux/install-sh'
> > libtoolize: copying file `config-aux/ltmain.sh'
> > libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to
> > configure.ac and
> > libtoolize: rerunning libtoolize, to keep the correct libtool macros
> > in- tree.
> > libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in
> > Makefile.am. autoreconf: running: /usr/bin/autoconf
> > autoreconf: running: /usr/bin/autoheader
> > autoreconf: running: automake --add-missing --copy --no-force
> > configure.ac:12: installing `config-aux/missing'
> > python/Makefile.am:20: installing `config-aux/py-compile'
> > src/Makefile.am: installing `config-aux/depcomp'
> > autoreconf: Leaving directory `.'
> > 
> > But make cannot find the makefile, and indeed there was not one
> > crea

Re: Need help with M$ touchmouse

[Gene Heskett]

On Friday 05 December 2014 17:01:56 Thomas Lübking did opine
And Gene did reply:
> On Freitag, 5. Dezember 2014 19:31:28 CEST, Gene Heskett wrote:
> > (II) LoadModule: "nouveau"
> > ...
> > (EE) [drm] failed to open device
> 
> See
> http://nouveau.freedesktop.org/wiki/TroubleShooting/#index1h3
> 
> From what I've read so far, I'd just bet that the updated kernel drm
> mismatches the XOrg driver.
> 
> > I reconfigured, built and installed a 3.16.0 kernel with the generic
> > fbdev
> 
> added to the mix.
> Again: this is NOT the kernel module, but the xorg driver.
> You need to update XOrg (also for a new nouveau driver) or (actually)
> the entire distro.
> 
> Building XOrg is far less time consuming than back then, when X11 came
> as a blob, but it requires you to know what you need and also (likely)
> to update some toolchain elements.
> 
> I deleted most of the conversation, but since this is apparently not a
> production system: is there anything holding you back from just
> upgrading the distro version (resp. install a brand new one in
> parallel) to get a state-of-the-art SW stack?
> 
> Cheers,
> Thomas

Other than the fact that even the LinuxCNC simulator would probably die, 
and that would put me standing up at a machines keyboard in a somewhat 
poorly heated shop building in the back yard.  Since I'm 80yo and my back 
is killing me after a half an hour of that, not much else.

But that wouldn't stop me from making the try at building a new X if its 
.configure script as as smart as most of the newer stuff seems to be.

Is it on git, or do I have to dl a tarball?

Thanks Thomas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Need help with M$ touchmouse

[Gene Heskett]

On Friday 05 December 2014 13:01:10 Gene Heskett did opine
And Gene did reply:
> On Friday 05 December 2014 12:42:24 Gene Heskett did opine
> 
> And Gene did reply:
> > On Friday 05 December 2014 12:23:19 Thomas Lط£آ¼bking did opine
> > 
> > And Gene did reply:
> > > On Freitag, 5. Dezember 2014 18:12:09 CEST, Gene Heskett wrote:
> > > > using the nouveau driver. From a 3.16.0 kernel tree I assume.
> > > 
> > > Doesn't seem so.
> > > 
> > > Posted log segment says, that you're trying to load nv, then unload
> > > it and ultimately seem to be running fbdev (what causes the mny
> > > error messages)
> > > 
> > > This is not about the kernel module, but the X11 driver.
> > > You'll need xserver-xorg-video-nouveau and libdrm-nouveau1, but
> > > rather not from 2010.
> > > 
> > > Cheers,
> > > Thomas
> > 
> > And how does one go about that?  Build & install Xorg from scratch?
> > 
> > I did that once about a decade & change back, on an old Red Hat
> > install, 6.1 IIRC. It worked, but was about a 2 hour build on that
> > old 400 mhz K6- II box with 320 megs of memory. :)
> > 
> > git URL?
> > 
> > > PS:
> > > http://www.freedesktop.org/wiki/Software/libevdev/ is the very
> > > first
> > 
> > Thanks Thomas, but what is the magic configure --with-??
> > that will get it to build the docs?
> > 
> > > goggle result here. ___
> > > xorg@lists.x.org: X.Org support
> > > Archives: http://lists.freedesktop.org/archives/xorg
> > > Info: http://lists.x.org/mailman/listinfo/xorg
> > > Your subscription address: %(user_address)s
> > 
> > Cheers, Gene Heskett
> 
> PS:
> I looked at some of the older Xorg logs, that error has been there,
> copiously and seemingly forever.  One of them was north of 500 megs!
> 
> So...
> 
> I reconfigured, built and installed a 3.16.0 kernel with the generic
> fbdev added to the mix.  But have not rebooted yet.  About to do that
> but it takes me about 10 minutes after a reboot to get all my
> workspaces set up. Boot timing is wrong from gkrellm so I always have
> to kill it and give the hardware monitor time to get its stuff in one
> sock, then restart it, and X always opens every console I had running
> when I issued the reboot, on workspace #1, and there are 10 of them. 9
> are busy ATM. For some strange reason, Kcalc is the only utility that
> remembers which workspace it was on. Everything else is piled up on
> workspace 1 & has to be moved to where it normally lives. :)
> 
> I write bash scripts for something like a kernel build/install so I
> don't have to remember (considering the years on the wet ram) all
> that. ;)
> 
> Anyway, reboot coming up.
> 
> Thanks Thomas.
> 
> Cheers, Gene Heskett

PS:  reboot done, but that error is still there, the log, by the time I 
got all my konsoles where they belong was up to 400k and growing.

And it is still unloading the nv driver, which I _thought_ was the nvidia 
driver.  And you are correct, the nouveau driver reports a 2010 code build 
date.  From the new log:

(==) Assigned the driver to the xf86ConfigLayout
(II) LoadModule: "nouveau"
(II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
(II) Module nouveau: vendor="X.Org Foundation"
compiled for 1.7.6, module version = 0.0.15
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 6.0
(II) LoadModule: "nv"
(II) Loading /usr/lib/xorg/modules/drivers/nv_drv.so
(II) Module nv: vendor="X.Org Foundation"
compiled for 1.7.3.901, module version = 2.1.15
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 6.0
(II) LoadModule: "vesa"
(II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
(II) Module vesa: vendor="X.Org Foundation"
compiled for 1.7.6, module version = 2.3.0
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 6.0
(II) LoadModule: "fbdev"
(II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
(II) Module fbdev: vendor="X.Org Foundation"
compiled for 1.7.6, module version = 0.4.1
ABI class: X.Org Video Driver, version 6.0
(II) NOUVEAU driver Date:   Wed Feb 10 18:43:39 2010 +0100
(II) NOUVEAU driver for NVIDIA chipset families :
RIVA TNT(NV04)
RIVA TNT2   (NV05)
GeForce 256 (NV10)
GeForce 2   (NV11, NV15)
GeForce 4MX (NV17, NV18)
GeForce 3   (NV20)
GeForce 4Ti (NV25, NV28)
GeForce FX  (NV3x)
GeForce 

Re: Need help with M$ touchmouse

[Gene Heskett]

On Friday 05 December 2014 12:42:24 Gene Heskett did opine
And Gene did reply:
> On Friday 05 December 2014 12:23:19 Thomas Lأ¼bking did opine
> 
> And Gene did reply:
> > On Freitag, 5. Dezember 2014 18:12:09 CEST, Gene Heskett wrote:
> > > using the nouveau driver. From a 3.16.0 kernel tree I assume.
> > 
> > Doesn't seem so.
> > 
> > Posted log segment says, that you're trying to load nv, then unload
> > it and ultimately seem to be running fbdev (what causes the mny
> > error messages)
> > 
> > This is not about the kernel module, but the X11 driver.
> > You'll need xserver-xorg-video-nouveau and libdrm-nouveau1, but
> > rather not from 2010.
> > 
> > Cheers,
> > Thomas
> 
> And how does one go about that?  Build & install Xorg from scratch?
> 
> I did that once about a decade & change back, on an old Red Hat
> install, 6.1 IIRC. It worked, but was about a 2 hour build on that old
> 400 mhz K6- II box with 320 megs of memory. :)
> 
> git URL?
> 
> > PS:
> > http://www.freedesktop.org/wiki/Software/libevdev/ is the very first
> 
> Thanks Thomas, but what is the magic configure --with-??
> that will get it to build the docs?
> 
> > goggle result here. ___
> > xorg@lists.x.org: X.Org support
> > Archives: http://lists.freedesktop.org/archives/xorg
> > Info: http://lists.x.org/mailman/listinfo/xorg
> > Your subscription address: %(user_address)s
> 
> Cheers, Gene Heskett

PS:
I looked at some of the older Xorg logs, that error has been there, 
copiously and seemingly forever.  One of them was north of 500 megs!

So...

I reconfigured, built and installed a 3.16.0 kernel with the generic fbdev 
added to the mix.  But have not rebooted yet.  About to do that but it 
takes me about 10 minutes after a reboot to get all my workspaces set up. 
Boot timing is wrong from gkrellm so I always have to kill it and give the 
hardware monitor time to get its stuff in one sock, then restart it, and X 
always opens every console I had running when I issued the reboot, on 
workspace #1, and there are 10 of them. 9 are busy ATM. For some strange 
reason, Kcalc is the only utility that remembers which workspace it was 
on. Everything else is piled up on workspace 1 & has to be moved to where 
it normally lives. :)

I write bash scripts for something like a kernel build/install so I don't 
have to remember (considering the years on the wet ram) all that. ;)

Anyway, reboot coming up.

Thanks Thomas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Need help with M$ touchmouse

[Gene Heskett]

On Friday 05 December 2014 12:23:19 Thomas Lübking did opine
And Gene did reply:
> On Freitag, 5. Dezember 2014 18:12:09 CEST, Gene Heskett wrote:
> > using the nouveau driver. From a 3.16.0 kernel tree I assume.
> 
> Doesn't seem so.
> 
> Posted log segment says, that you're trying to load nv, then unload it
> and ultimately seem to be running fbdev (what causes the mny error
> messages)
> 
> This is not about the kernel module, but the X11 driver.
> You'll need xserver-xorg-video-nouveau and libdrm-nouveau1, but rather
> not from 2010.
> 
> Cheers,
> Thomas

And how does one go about that?  Build & install Xorg from scratch?

I did that once about a decade & change back, on an old Red Hat install, 
6.1 IIRC. It worked, but was about a 2 hour build on that old 400 mhz K6-
II box with 320 megs of memory. :)

git URL?

> PS:
> http://www.freedesktop.org/wiki/Software/libevdev/ is the very first

Thanks Thomas, but what is the magic configure --with-??
that will get it to build the docs?

> goggle result here. ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Need help with M$ touchmouse

[Gene Heskett]

On Friday 05 December 2014 08:57:50 Thomas Lübking did opine
And Gene did reply:
> On Freitag, 5. Dezember 2014 03:43:44 CEST, Gene Heskett wrote:
> > (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
> 
> You might want to check whether there's a usable driver for your
> graphics chip provided by even that version of Ubuntu.
> 
> Cheers,
> Thomas

About a 3 yo lower range (about $80 when I bought it) nvidia card, a 
GForce 8400GS, using the nouveau driver. From a 3.16.0 kernel tree I 
assume.

And I am not about to install the nvida drivers for the simple reason that 
the install marries that driver to the kernel you are running, and 
installing an updated kernel is subject to re-installing the system 
because you can never get rid of enough of the older driver so the newer 
driver will allow itself to be installed.  I spent about 3 days screwing 
around trying to install an updated nvidia driver after building a newer 
kernel, and managed to destroy the system & had to buy a new drive & 
install from scratch.  When nvidia gets their head out of their ass and 
quits that bull shit so one can update his kernel without a 3 day battle I 
know I am going to lose, I might consider it. Until then the nouveau 
driver will have to do.

NVidia I think, seems to make a quite usable video card, so I'll stick 
with them.  I do wish the makers and vendors of their designs would spend 
another dollar for their fans though.  This one is 2 years old & rattling 
like a 40 yo 2CV on a rutted road.

So do the folks over at what is now AMD, they do make a decent product, 
usually longer lasting, but Alex has yet to release a driver for one of 
their cards until it is at least 2 years out of the supply lines and 
unable to be purchased from any source.  Sure, they've released a newer 
card, but its not compatible with the currently available drivers and its 
as bad as dealing with an nvidia install to get rid of it.  Divorces are 
way too costly  I don't need that pain, I have enough of that from my now 
80yo and abused back.

Here is a rant about my experiences with ATI cards, about 8 of them over 
the last 15 years in about that many machines (I have more than this 
machine running here, there are, because my lathe and milling machine are 
both CNC'd and running LinuxCNC, at minimum 3 boxes running 24/7) here:

Over the years Alex D.has promised me updated drivers for my ATI card (I 
like to support the underdog else we'll have a market monopoly like M$ has 
in the department stores) 5 or 6 times now, so that garden path, well 
traveled and trodden solidly over the years, has been explored with around 
$500 worth of ATI cards, none of which would ever work with anything but 
the screen size crippled vesa driver.  Then, when ATI does throw code over 
the fence, my now 2 year old card I bought because of that promise is too 
old for the new drivers.

So I ask what cards the new driver does support, get a list, but newegg 
hasn't had one of those in years.

So I'm sorry Alex and I know thats a marketing thing at ATI, but until you 
can synchronize the linux code for the cards I can actually buy, no 
further ATI cards will be considered for purchase. I keep thinking that 
bullet hole in ATI's linux facing foot would heal, but until it does, ATI 
is DITW for us long time linux users, 15 years for this one, who does 
not allow a windows machine on the premises.

Sure, we aren't a majority of the computer users, but anyone who wants the 
market WILL support the linux user at least as well as you support the 
M$(spit) users. ATI has not.

/rant off.

Thank you Thomas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Need help with M$ touchmouse

[Gene Heskett]

On Thursday 04 December 2014 23:03:38 Peter Hutterer did opine
And Gene did reply:
> On Thu, Dec 04, 2014 at 09:43:44PM -0500, Gene Heskett wrote:
> > On Thursday 04 December 2014 16:18:16 Peter Hutterer did opine
> > 
> > And Gene did reply:
> > > On Thu, Dec 04, 2014 at 01:23:49PM -0500, Gene Heskett wrote:
> > > > Greetings all;
> > > > 
> > > > I have a wireless M$ Explorer Touchmouse, and the touch pad is
> > > > buggier than a 10 day old carcass.
> > > > 
> > > > Specifically, the side scrolling is driving me crazy, and its not
> > > > a long trip. ;)
> > > > 
> > > > When it works, its 20x more sensitive sideways than vertically,
> > > > and I can't get my fingers far enough away from the pad to stop
> > > > its crazy behavior, and still rest them in a comfy location for
> > > > button pushing.
> > > > 
> > > > Is there anything I can put in an /etc/X11 file that will shut
> > > > the side scroll function off, but leave the vertical finger
> > > > drags working?
> > > 
> > > attach an evemu recording and your xorg.log to a bug please. I
> > > don't have a recording for this one yet so it's hard to tell.
> > > 
> > > Cheers,
> > > 
> > >Peter
> > 
> > First off Peter, evemu is not 'locate'able.  And I'm not sure you
> > want the current Xorg.0.log in your mailbox as its north of 179
> > megabytes.
> 
> you could have restarted X, or started another session for a fresh log
> file. or cut down the thousands of lines of errors which is likely
> what 99% of the log file are if it grows to that size in a week.
> 
> > I even sicc'd synaptic to find it in the ubuntu repo, and came up dry
> > there too.
> 
> evemu shows up as second link on google for me:
> http://www.freedesktop.org/wiki/Evemu/
> 
> but tbh, if you're on a 4 year old box you're pretty much on your own,
> sorry. there may have been kernel fixes since, there may have been
> evdev fixes since, etc.

I do occsionally build a fresher kernel because the default kernel for 
this particular install, an rtai kit on top of 2.6.32-123, has no PAE and 
there's 8Gb in this box.  Running the OEM kernel only sees 3Gb of that, 
and I'm a gigabyte into swap in 24hrs.

So the presently running kernel is a 3.16.0.  32 bit with PAE.  Hasn't 
touched swap in months.

Nest, that link 3rd line is bogus, needs an ".sh" tagged onto the 
./autogen script cli invocation.

The autogen output this to the screen:
gene@coyote:/usr/src/evemu$ ./autogen.sh --prefix=/usr
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal 
autoreconf: configure.ac: tracing
autoreconf: configure.ac: creating directory config-aux
autoreconf: running: libtoolize --install --copy
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `config-aux'.
libtoolize: copying file `config-aux/config.guess'
libtoolize: copying file `config-aux/config.sub'
libtoolize: copying file `config-aux/install-sh'
libtoolize: copying file `config-aux/ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac 
and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-
tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:12: installing `config-aux/missing'
python/Makefile.am:20: installing `config-aux/py-compile'
src/Makefile.am: installing `config-aux/depcomp'
autoreconf: Leaving directory `.'

But make cannot find the makefile, and indeed there was not one created.
The INSTALL inserts a ./configure step in the sequence, and that bails out 
for lack of:

checking pkg-config is at least version 0.9.0... yes
checking for LIBEVDEV... configure: error: Package requirements (libevdev 
>= 1.2.99.902) were not met:

No package 'libevdev' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LIBEVDEV_CFLAGS
and LIBEVDEV_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

Apparently I'll need a git URL to get it and install it?  Amazingly that 
gets zero hits on google.  You have found the ultimate google non-entity!  
That has NEVER happened before.

So you see what I need to do above and I am waiting, with "baited" breath 
for further instruction. ;-)

Thanks Peter.
 
> Cheers,
&g

Re: Need help with M$ touchmouse

[Gene Heskett]

On Thursday 04 December 2014 16:18:16 Peter Hutterer did opine
And Gene did reply:
> On Thu, Dec 04, 2014 at 01:23:49PM -0500, Gene Heskett wrote:
> > Greetings all;
> > 
> > I have a wireless M$ Explorer Touchmouse, and the touch pad is
> > buggier than a 10 day old carcass.
> > 
> > Specifically, the side scrolling is driving me crazy, and its not a
> > long trip. ;)
> > 
> > When it works, its 20x more sensitive sideways than vertically, and I
> > can't get my fingers far enough away from the pad to stop its crazy
> > behavior, and still rest them in a comfy location for button pushing.
> > 
> > Is there anything I can put in an /etc/X11 file that will shut the
> > side scroll function off, but leave the vertical finger drags
> > working?
> 
> attach an evemu recording and your xorg.log to a bug please. I don't
> have a recording for this one yet so it's hard to tell.
> 
> Cheers,
>Peter

First off Peter, evemu is not 'locate'able.  And I'm not sure you want the 
current Xorg.0.log in your mailbox as its north of 179 megabytes.
I even sicc'd synaptic to find it in the ubuntu repo, and came up dry 
there too.

This is a 10.04.4 LTS server install with enough kde pulled in to get 
kmail & friends.

I can copy/paste the relevant module loading bits. Here if it would help.

THere is about 160 megabytes of this in the log:

 (II) LoadModule: "fb"
(II) Loading /usr/lib/xorg/modules/libfb.so
(II) Module fb: vendor="X.Org Foundation"
compiled for 1.7.6, module version = 1.0.0
ABI class: X.Org ANSI C Emulation, version 0.4
(**) FBDEV(0): using shadow framebuffer
(II) Loading sub module "shadow"
(II) LoadModule: "shadow"
(II) Loading /usr/lib/xorg/modules/libshadow.so
(II) Module shadow: vendor="X.Org Foundation"
compiled for 1.7.6, module version = 1.1.0
ABI class: X.Org ANSI C Emulation, version 0.4
(II) UnloadModule: "nv"
(II) Unloading /usr/lib/xorg/modules/drivers/nv_drv.so
(==) Depth 24 pixmap format is 32 bpp
(==) FBDEV(0): Backing store disabled
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument


Which is repeated at least 1000 times, then later after it has found my 
pcHDTV-3000 card:

(II) MCE IR Keyboard/Mouse (cx88xx): initialized for relative axes.
(II) config/udev: Adding input device MCE IR Keyboard/Mouse (cx88xx) 
(/dev/input/mouse0)
(II) No input driver/identifier specified (ignoring)
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
(EE) FBDEV(0): FBIOPUTCMAP: Invalid argument

I'd guess another 165 megabytes of that to the end of the log.  Uptime is 
a week & small change.

I didn't even know the tv card had a mouse port?  But I'll be dipped, it 
actually has a ps2 socket on the back of it!  But I'm not sure I still 
have one of those critters.

> > Even that goes away quite frequently, and I have to turn the mouse
> > over, shut it off for a second or two & turn it back on, at which
> > point it works fairly well but will eventually become intermittent
> > in its response for an hour or so before completely dying, the the
> > screen cursor still follows it well, and the two buttons work well. 
> > But I've blamed that on a buggy mouse.
> > 
> > This is extremely distracting when I am writing code in geany (gedit
> > does not have a sideways scroll, but it has trashed important source
> > code file entirly too often, geany never has) because I have to drag
> > the bar on the bottom back the the left stop in order to see what I
> > am writing.  I need help since the mouse makers figured out how to
> > sell the high priced versions by putting the optical eye way back
> > under the palm of our hands instead of up under your fingers in the
> > #<$50 models.  So the <$50 mice aren't at all intuitive to use
> > because you are forced to move the whole arm when using them.


Thanks Peter.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that o

Need help with M$ touchmouse

[Gene Heskett]

Greetings all;

I have a wireless M$ Explorer Touchmouse, and the touch pad is buggier 
than a 10 day old carcass.

Specifically, the side scrolling is driving me crazy, and its not a long 
trip. ;)

When it works, its 20x more sensitive sideways than vertically, and I 
can't get my fingers far enough away from the pad to stop its crazy 
behavior, and still rest them in a comfy location for button pushing.

Is there anything I can put in an /etc/X11 file that will shut the side 
scroll function off, but leave the vertical finger drags working?

Even that goes away quite frequently, and I have to turn the mouse over, 
shut it off for a second or two & turn it back on, at which point it works 
fairly well but will eventually become intermittent in its response for an 
hour or so before completely dying, the the screen cursor still follows it 
well, and the two buttons work well.  But I've blamed that on a buggy 
mouse.

This is extremely distracting when I am writing code in geany (gedit does 
not have a sideways scroll, but it has trashed important source code file 
entirly too often, geany never has) because I have to drag the bar on the 
bottom back the the left stop in order to see what I am writing.  I need 
help since the mouse makers figured out how to sell the high priced 
versions by putting the optical eye way back under the palm of our hands 
instead of up under your fingers in the #<$50 models.  So the <$50 mice 
aren't at all intuitive to use because you are forced to move the whole 
arm when using them.

Thanks guys & gals.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: cannot open gedit

[Gene Heskett]

On Friday 26 September 2014 17:29:15 XUTIANRUI did opine
And Gene did reply:
> Hi,
> I have just installed XQuartz 2.7.7 to my Mac. However after I:
> % ssh -X
> to a remote server, and type
> % gedit somename.py &
> in order to open a gedit window to edit, there is a window showing up
> for a second and then vanishes. May I ask why?
> Thank you.
> Terah

ssh -X doesn't always grab the X stuff, try ssh -Y

You must also be the same user on both machines.  So if you're on a buntu 
box, ssh-ing into a redhat/fedora box, you will have to look up the ssh 
manpage and use the username and password that is you on the rh/fedora 
box.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Radeon rv610 (2400HD-Pro card) question

[Gene Heskett]

On Friday 07 February 2014 19:23:24 Alex Deucher did opine:

> On Fri, Feb 7, 2014 at 3:34 PM, Gene Heskett  
wrote:
> > On Friday 07 February 2014 14:46:43 Alex Deucher did opine:
> >> On Wed, Feb 5, 2014 at 11:05 PM, Gene Heskett  
wrote:
> >> > Greetings;
> >> > 
> >> > Since it appears nvidia is not supporting the econo cards in the
> >> > supply pipeline, cards like the 8400 GS I just bought 2 of, I got
> >> > the bright idea to swap it out for an old radeon 2400HD-Pro card I
> >> > had on the shelf.  So I built a 3.13.1 32 bit kernel and rebooted
> >> > after changing teh card.
> >> > 
> >> > Color is nice, looks like a higher gamma setting.  But video speed
> >> > is just as bad and the audio was about 1.5 MINUTES behind the
> >> > video, as the nvidia card I took out on the news sites, so I
> >> > toddled over to youtube to see. Video played at about 2x normal
> >> > speeds, and the audio was still 1 minutes and change after the
> >> > video.
> >> > 
> >> > I've see stuff out of sync before, but over a minute?
> >> > 
> >> > Called up synaptic & found there were some codecs I didn't have, so
> >> > I
> >> 
> >> > installed those, BUT another kernel rebuild reports:
> >> We are going to need a bit more information.  Which driver were you
> >> using fglrx or the open source driver?  What app were you using to
> >> play the video?  What API (Xv, X11, VDAPU, GL, etc.).  Is the driver
> >> installed and working properly?  How are you trying to play the
> >> audio?
> >> 
> >>  Via hdmi, via a 1/8 headphone jack, something else?  At the minimum,
> >> 
> >> we'd need your xorg log, dmesg output, and glxinfo output.  From your
> >> second email, it sounds like something is seriously screwed up on
> >> your system if gears is segfaulting.  If you previously had fglrx
> >> installed, you will need to re-install several of your disto
> >> packages because the closed source drivers (both nvidiia and fglrx)
> >> overwrite several gl and glx libs.
> >> 
> >> Alex
> > 
> > No closed nvidia drivers, all nouveau. Top level apps were firefox27
> > or chromium.  And to get something that attempts to work, I've
> > swapped back to the nvidia card.  I figured 2 days was long enough to
> > wait for a reply, and zero traffic from the list in that 2 days, and
> > I needed something quasi- usable.  If we can keep a conversation
> > going, I will switch back.
> 
> It's up to you, I didn't have time to look at this until today.
> 
> > Audio is a small amplified 3 speaker set plugged into line out on the
> > asus motherboards HDA Intel audio.  Too heavy on bass, but no
> > controls.
> > 
> > xorg.0.log attached, but as you know, that is replaced on every startx
> > or equ.  So this one represents the nvidia card boot.  Looks to be an
> > endless framebuffer error in places.
> > 
> > I just reinstalled ALL the OpenGL and msa-glx stuff, no change,
> > glxgears is still a segfault. I didn't uninstall the flgrx stuff, but
> > didn't reinstall it either.
> > 
> > I am also building kernels a couple times a day, trying to get a
> > 3.13.1 to boot, but its hanging at top_init.  This is 3.12.9 ATM.
> 
> According to your log you are using the fbdev X driver which is
> software rendering.  I suspect you were probably using the fbdev
> driver for the AMD card as well.  I suspect perhaps the kernel drivers
> are not loaded properly on your system.  Double check to  make sure
> the kernel drivers are not blacklisted.  Note that fglrx blacklists
> the open source radeon kernel driver so that it doesn't load when
> fglrx is installed.  The open source radeon driver may still be
> blacklisted.  Check your dmesg output to see if the kernel graphics
> driver is loaded properly.  I'm not sure what's going on with the
> nouveau driver.
> 
> Alex

I will swap the cards back tomorrow, and check all of the above.  Atm, the 
fb is the nouveaufb according to dmesg.  And the blacklistings files are 
there, so I'll remove fglrx and nuke them before I shut down to swap the 
cards.

Thanks Alex.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Radeon rv610 (2400HD-Pro card) question

[Gene Heskett]

On Friday 07 February 2014 12:17:20 Gene Heskett did opine:

> Greetings;
> 
> Since it appears nvidia is not supporting the econo cards in the supply
> pipeline, cards like the 8400 GS I just bought 2 of, I got the bright
> idea to swap it out for an old radeon 2400HD-Pro card I had on the
> shelf.  So I built a 3.13.1 32 bit kernel and rebooted after changing
> teh card.
> 
> Color is nice, looks like a higher gamma setting.  But video speed is
> just as bad and the audio was about 1.5 MINUTES behind the video, as
> the nvidia card I took out on the news sites, so I toddled over to
> youtube to see. Video played at about 2x normal speeds, and the audio
> was still 1 minutes and change after the video.
> 
> I've see stuff out of sync before, but over a minute?
> 
> Called up synaptic & found there were some codecs I didn't have, so I
> installed those, BUT another kernel rebuild reports:
> 
> now making a new /boot/initrd.3.13.1.img
> W: Possible missing firmware /lib/firmware/radeon/CYPRESS_smc.bin for
> module radeon W: Possible missing firmware
> /lib/firmware/radeon/JUNIPER_smc.bin for module radeon W: Possible
> missing firmware /lib/firmware/radeon/REDWOOD_smc.bin for module radeon
> W: Possible missing firmware /lib/firmware/radeon/CEDAR_smc.bin for
> module radeon W: Possible missing firmware
> /lib/firmware/radeon/RV710_smc.bin for module radeon W: Possible
> missing firmware /lib/firmware/radeon/RV740_smc.bin for module radeon
> W: Possible missing firmware /lib/firmware/radeon/RV730_smc.bin for
> module radeon W: Possible missing firmware
> /lib/firmware/radeon/RV770_smc.bin for module radeon W: Possible
> missing firmware /lib/firmware/radeon/ARUBA_rlc.bin for module radeon
> W: Possible missing firmware /lib/firmware/radeon/ARUBA_me.bin for
> module radeon W: Possible missing firmware
> /lib/firmware/radeon/ARUBA_pfp.bin for module radeon W: Possible
> missing firmware /lib/firmware/radeon/CAYMAN_smc.bin for module radeon
> W: Possible missing firmware /lib/firmware/radeon/CAICOS_smc.bin for
> module radeon W: Possible missing firmware
> /lib/firmware/radeon/TURKS_smc.bin for module radeon W: Possible
> missing firmware /lib/firmware/radeon/BARTS_smc.bin for module radeon
> W: Possible missing firmware /lib/firmware/radeon/HAINAN_smc.bin for
> module radeon W: Possible missing firmware
> /lib/firmware/radeon/HAINAN_rlc.bin for module radeon W: Possible
> missing firmware /lib/firmware/radeon/HAINAN_mc.bin for module radeon
> W: Possible missing firmware /lib/firmware/radeon/HAINAN_ce.bin for
> module radeon W: Possible missing firmware
> /lib/firmware/radeon/HAINAN_me.bin for module radeon W: Possible
> missing firmware /lib/firmware/radeon/HAINAN_pfp.bin for module radeon
> W: Possible missing firmware /lib/firmware/radeon/OLAND_smc.bin for
> module radeon W: Possible missing firmware
> /lib/firmware/radeon/OLAND_rlc.bin for module radeon W: Possible
> missing firmware /lib/firmware/radeon/OLAND_mc.bin for module radeon W:
> Possible missing firmware /lib/firmware/radeon/OLAND_ce.bin for module
> radeon W: Possible missing firmware /lib/firmware/radeon/OLAND_me.bin
> for module radeon W: Possible missing firmware
> /lib/firmware/radeon/OLAND_pfp.bin for module radeon W: Possible
> missing firmware /lib/firmware/radeon/VERDE_smc.bin for module radeon
> W: Possible missing firmware /lib/firmware/radeon/VERDE_rlc.bin for
> module radeon W: Possible missing firmware
> /lib/firmware/radeon/VERDE_mc.bin for module radeon W: Possible missing
> firmware /lib/firmware/radeon/VERDE_ce.bin for module radeon W:
> Possible missing firmware /lib/firmware/radeon/VERDE_me.bin for module
> radeon W: Possible missing firmware /lib/firmware/radeon/VERDE_pfp.bin
> for module radeon W: Possible missing firmware
> /lib/firmware/radeon/PITCAIRN_smc.bin for module radeon W: Possible
> missing firmware /lib/firmware/radeon/PITCAIRN_rlc.bin for module
> radeon W: Possible missing firmware
> /lib/firmware/radeon/PITCAIRN_mc.bin for module radeon W: Possible
> missing firmware /lib/firmware/radeon/PITCAIRN_ce.bin for module radeon
> W: Possible missing firmware /lib/firmware/radeon/PITCAIRN_me.bin for
> module radeon W: Possible missing firmware
> /lib/firmware/radeon/PITCAIRN_pfp.bin for module radeon W: Possible
> missing firmware /lib/firmware/radeon/TAHITI_smc.bin for module radeon
> W: Possible missing firmware /lib/firmware/radeon/TAHITI_rlc.bin for
> module radeon W: Possible missing firmware
> /lib/firmware/radeon/TAHITI_mc.bin for module radeon W: Possible
> missing firmware /lib/firmware/radeon/TAHITI_ce.bin for module radeon
> W: Possible missing firmware /lib/firmware/radeon/TAHITI_me.bin for
> module radeon W: Possible missing firmware
> /lib/firmware/rad

Radeon rv610 (2400HD-Pro card) question

[Gene Heskett]

Greetings;

Since it appears nvidia is not supporting the econo cards in the supply
pipeline, cards like the 8400 GS I just bought 2 of, I got the bright idea 
to swap it out for an old radeon 2400HD-Pro card I had on the shelf.  So I 
built a 3.13.1 32 bit kernel and rebooted after changing teh card.

Color is nice, looks like a higher gamma setting.  But video speed is just 
as bad and the audio was about 1.5 MINUTES behind the video, as the nvidia 
card I took out on the news sites, so I toddled over to youtube to see.  
Video played at about 2x normal speeds, and the audio was still 1 minutes 
and change after the video.

I've see stuff out of sync before, but over a minute?

Called up synaptic & found there were some codecs I didn't have, so I 
installed those, BUT another kernel rebuild reports:

now making a new /boot/initrd.3.13.1.img
W: Possible missing firmware /lib/firmware/radeon/CYPRESS_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/JUNIPER_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/REDWOOD_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/CEDAR_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/RV710_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/RV740_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/RV730_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/RV770_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/ARUBA_rlc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/ARUBA_me.bin for module radeon
W: Possible missing firmware /lib/firmware/radeon/ARUBA_pfp.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/CAYMAN_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/CAICOS_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/TURKS_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/BARTS_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/HAINAN_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/HAINAN_rlc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/HAINAN_mc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/HAINAN_ce.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/HAINAN_me.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/HAINAN_pfp.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/OLAND_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/OLAND_rlc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/OLAND_mc.bin for module radeon
W: Possible missing firmware /lib/firmware/radeon/OLAND_ce.bin for module radeon
W: Possible missing firmware /lib/firmware/radeon/OLAND_me.bin for module radeon
W: Possible missing firmware /lib/firmware/radeon/OLAND_pfp.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/VERDE_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/VERDE_rlc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/VERDE_mc.bin for module radeon
W: Possible missing firmware /lib/firmware/radeon/VERDE_ce.bin for module radeon
W: Possible missing firmware /lib/firmware/radeon/VERDE_me.bin for module radeon
W: Possible missing firmware /lib/firmware/radeon/VERDE_pfp.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/PITCAIRN_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/PITCAIRN_rlc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/PITCAIRN_mc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/PITCAIRN_ce.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/PITCAIRN_me.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/PITCAIRN_pfp.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/TAHITI_smc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/TAHITI_rlc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/TAHITI_mc.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/TAHITI_ce.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/TAHITI_me.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/TAHITI_pfp.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/BONAIRE_uvd.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/TAHITI_uvd.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/SUMO_uvd.bin for module radeon
W: Possible missing firmware /lib/firmware/radeon/CYPRESS_uvd.bin for module 
radeon
W: Possible missing firmware /lib/firmware/radeon/RV710_uvd

nouveau question

[Gene Heskett]

Greetings all;

Is there any hope of getting a driver for this video card:

gene@coyote:/etc/init.d$ dmesg|grep nouveau
[1.743185] nouveau  [  DEVICE][:03:00.0] BOOT0  : 0x0a8180b1
[1.743233] nouveau  [  DEVICE][:03:00.0] Chipset: GT218 (NVA8)
[1.743273] nouveau  [  DEVICE][:03:00.0] Family : NV50
[1.744354] nouveau  [   VBIOS][:03:00.0] checking PRAMIN for image...
[1.810394] nouveau  [   VBIOS][:03:00.0] ... appears to be valid
[1.810434] nouveau  [   VBIOS][:03:00.0] using image from PRAMIN
[1.810613] nouveau  [   VBIOS][:03:00.0] BIT signature found
[1.810675] nouveau  [   VBIOS][:03:00.0] version 70.18.5f.00.00
[1.810973] nouveau  [ PFB][:03:00.0] RAM type: DDR3
[1.811019] nouveau  [ PFB][:03:00.0] RAM size: 1024 MiB
[1.811065] nouveau  [ PFB][:03:00.0]ZCOMP: 960 tags
[2.453221] nouveau  [  PTHERM][:03:00.0] FAN control: none / external
[2.453273] nouveau  [  PTHERM][:03:00.0] fan management: disabled
[2.453322] nouveau  [  PTHERM][:03:00.0] internal sensor: yes
[2.453691] nouveau  [ DRM] VRAM: 1024 MiB
[2.453735] nouveau  [ DRM] GART: 1048576 MiB
[2.453781] nouveau  [ DRM] TMDS table version 2.0
[2.453827] nouveau  [ DRM] DCB version 4.0
[2.453873] nouveau  [ DRM] DCB outp 00: 01000302 00020030
[2.453920] nouveau  [ DRM] DCB outp 01: 02000300 
[2.453959] nouveau  [ DRM] DCB outp 02: 02011362 00020010
[2.454004] nouveau  [ DRM] DCB outp 03: 01022310 
[2.454056] nouveau  [ DRM] DCB conn 00: 1030
[2.454118] nouveau  [ DRM] DCB conn 01: 2161
[2.454187] nouveau  [ DRM] DCB conn 02: 0200
[2.463698] nouveau  [ DRM] 3 available performance level(s)
[2.463747] nouveau  [ DRM] 0: core 135MHz shader 270MHz memory 135MHz 
voltage 850mV
[2.463805] nouveau  [ DRM] 1: core 405MHz shader 810MHz memory 405MHz 
voltage 900mV
[2.463863] nouveau  [ DRM] 3: core 520MHz shader 1238MHz memory 600MHz 
voltage 1000mV
[2.463919] nouveau  [ DRM] c: core 405MHz shader 810MHz memory 405MHz 
voltage 900mV
[2.474053] nouveau  [ DRM] MM: using COPY for buffer copies
[2.517306] nouveau  [ DRM] allocated 1920x1080 fb: 0x7, bo f7222a00
[2.517421] fbcon: nouveaufb (fb0) is primary device
[2.585123] nouveau :03:00.0: fb0: nouveaufb frame buffer device
[2.585133] nouveau :03:00.0: registered panic notifier
[2.585149] [drm] Initialized nouveau 1.1.1 20120801 for :03:00.0 on 
minor 0

That can play a news video from the MSN sites?

I have a 10 megabaud net circuit, but the videos play like a 28.8k dialup.
Getting about 1/4 second of video and audio, 3/4 second of frozen silence
now.  Repeat till I'm driven out of my skull and hit the quit button.

Or are there any options I can set in an /etc/X11/xorg.conf that would help?

FWIW, turning off the hardware accel in FF actually helps.

Currently on an X86_32, 3.12.6 PAE 32 bit kernel.

Thanks.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

Feminists just want the human race to be a tie.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [ANNOUNCE] xf86-video-ati 7.3.0

[Gene Heskett]

On Saturday 25 January 2014 15:33:58 Alex Deucher did opine:

> I guess gmail mangled it.  Does the attached work any better?
> 
> 
> Alex
> 
> On Sat, Jan 25, 2014 at 9:24 AM, Julien Cristau  
wrote:
> > Hi Alex,
> > 
> > When trying to verify this message, I get
> > gpg: BAD signature from "Alex Deucher "
> > 
> > :(
> > 
> > If this isn't just me, any chance to get the tarball checksums in a
> > properly signed mail?
> > 
> > Thanks,
> > Julien
No fussing here Alex.

Suggestion:  Junk gmail. Gmails unwanted editing of posts is the single 
highest squawk generator on the planet.  I've been using kde since 
1.something days, and once you have written some scripts to offload some of 
its background stuff, it Just Works.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

Love IS what it's cracked up to be.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [ANNOUNCE] xf86-video-ati 7.3.0

[Gene Heskett]

On Saturday 25 January 2014 14:54:23 Brad Rogers did opine:

> On Sat, 25 Jan 2014 14:03:14 -0500
> Gene Heskett  wrote:
> 
> Hello Gene,
> 
> >It came from j...@eukor.com.  As was noted in my initial response.
> 
> Sorry, I missed that.  Neither did I see the message;  It got binned
> before reaching my MUA.

It should have been here, but I neglected to ascertain the source IP & add 
it to my mailfilter database.  My bad, only been using it for 4 years now.

Sigh...
> 
> Right, normal service, etc. etc.


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

Dignity is like a flag.  It flaps in a storm.
-- Roy Mengot
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: [ANNOUNCE] xf86-video-ati 7.3.0

[Gene Heskett]

On Saturday 25 January 2014 13:59:30 Brad Rogers did opine:

> On Sat, 25 Jan 2014 13:06:36 -0500
> Gene Heskett  wrote:
> 
> Hello Gene,
> 
> >No, here, when I enabled the html display of that poorly composed
> >message,
> 
> Alex's message had no HTML?  Are you sure you're talking about his
> perfectly legitimate post to the list?

It wasn't Alex's message, it was from what I assumed to be some other 
subscriber.  I've nuked that particular message.

It came from j...@eukor.com.  As was noted in my initial response.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

"The following is not for the weak of heart or Fundamentalists."
-- Dave Barry
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [ANNOUNCE] xf86-video-ati 7.3.0

[Gene Heskett]

On Saturday 25 January 2014 12:58:50 Brad Rogers did opine:

> On Sat, 25 Jan 2014 12:00:56 -0500
> Gene Heskett  wrote:
> 
> Hello Gene,
> 
> >This stuff doesn't work for mailing lists, and whom ever's bright idea
> 
> What stuff?  PGP Signing?

No, here, when I enabled the html display of that poorly composed message, 
I find a registration screen that if completed, would allow me to send mail 
to the idiot.  I have no intention of registering myself with yet another 
spammer so he can sell it to the highest bidder.  Registering to be 
whitelisted or whatever they call it, was a bum idea from the gitgo, and I 
thought it had died the torturous death it deserved 5 or 6 years ago.

Here, I have a fairly simple rule about spam.  An incoming is searched for 
the originating IP, and that whole class d gets deleted from the pop server 
without ever being downloaded to my box again.  I watch its logs for FP's, 
and in the nominally 4 years I have been doing that, haven't found one.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

"It's men like him that give the Y chromosome a bad name."
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [ANNOUNCE] xf86-video-ati 7.3.0

[Gene Heskett]

On Saturday 25 January 2014 11:59:17 j...@eukor.com did opine:

> 

This stuff doesn't work for mailing lists, and whom ever's bright idea it 
is should be unsubscribed, forthwith.  If not sooner.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

This will be a memorable month -- no matter how hard you try to forget it.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [ANNOUNCE] xf86-video-ati 7.3.0

[Gene Heskett]

On Saturday 25 January 2014 11:57:01 Claus Assmann did opine:

> On Sat, Jan 25, 2014, Julien Cristau wrote:
> > gpg: BAD signature from "Alex Deucher "
> 
> Same here.

There's an echo in here.
> 
> > If this isn't just me, any chance to get the tarball checksums in a
> > properly signed mail?
> 
> Hmm, maybe it would be a good idea to have signed tar files
> (on the server)?
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

This will be a memorable month -- no matter how hard you try to forget it.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question needs asked

[Gene Heskett]

On Friday 17 January 2014 00:52:42 Gene Heskett did opine:

> On Friday 17 January 2014 00:51:17 Gene Heskett did opine:
> > Greetings all;
> > 
> > I had to replace my GeForce 9400gt card about 3 weeks ago because the
> > color mapping was going in the toilet, and put a EVGA 8400GS in its
> > place, still using the nouveau driver.
> > 
> > Video performance can best be described as sucking dead toads through
> > soda straws, long 4 or 5 second pauses then catchups, which also cut
> > the sound to mostly unintelligible gibberish.
> > 
> > Is there anything that can be done?  I note this newer card isn't
> > listed in the man page.  If support is "in progress" I can wait, with
> > "baited" breath, if not, can anyone suggest a usable card, not an
> > AMD/ATI related one, that this older driver still supports, and which
> > is still in the supply pipeline and purchasable for under say $75
> > USD?
> > 
> > Cheers, Gene
> 
> Ping, and thanks.
>
Felix Miata, just to note, I did reply to your query yesterday, even 
attaching the Xorg.0.log, but it must have been to big for the server 
because I never got the echo back from the list.

Kernel is 32 bit PAE 3.12.6, cpu is Phenom 9550, 8 gigs of dram.  Install 
is ubuntu 10.04.4 LTS, frozen by an app that will not run on a later 
kernel, so I keep the original rtai patched kernel handy for when I need to 
run that app.

Is there anything specific I can copy/paste from the Xorg.0.log?
 
> Cheers, Gene


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Required reading: 
<http://culturalslagheap.wordpress.com/2014/01/12/elemental/>
You just wait, I'll sin till I blow up!
-- Dylan Thomas
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Question needs asked

[Gene Heskett]

On Friday 17 January 2014 00:51:17 Gene Heskett did opine:

> Greetings all;
> 
> I had to replace my GeForce 9400gt card about 3 weeks ago because the
> color mapping was going in the toilet, and put a EVGA 8400GS in its
> place, still using the nouveau driver.
> 
> Video performance can best be described as sucking dead toads through
> soda straws, long 4 or 5 second pauses then catchups, which also cut
> the sound to mostly unintelligible gibberish.
> 
> Is there anything that can be done?  I note this newer card isn't listed
> in the man page.  If support is "in progress" I can wait, with "baited"
> breath, if not, can anyone suggest a usable card, not an AMD/ATI
> related one, that this older driver still supports, and which is still
> in the supply pipeline and purchasable for under say $75 USD?
> 
> Cheers, Gene

Ping, and thanks.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Required reading: 
<http://culturalslagheap.wordpress.com/2014/01/12/elemental/>
You just wait, I'll sin till I blow up!
-- Dylan Thomas
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Question needs asked

[Gene Heskett]

Greetings all;

I had to replace my GeForce 9400gt card about 3 weeks ago because the color 
mapping was going in the toilet, and put a EVGA 8400GS in its place, still 
using the nouveau driver.

Video performance can best be described as sucking dead toads through soda 
straws, long 4 or 5 second pauses then catchups, which also cut the sound 
to mostly unintelligible gibberish.

Is there anything that can be done?  I note this newer card isn't listed in 
the man page.  If support is "in progress" I can wait, with "baited" 
breath, if not, can anyone suggest a usable card, not an AMD/ATI related 
one, that this older driver still supports, and which is still in the 
supply pipeline and purchasable for under say $75 USD?

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

If I had to live my life again, I'd make the same mistakes, only sooner.
-- Tallulah Bankhead
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

command translation needed.

[Gene Heskett]

Due to some conflicts which I have not been able to run down, I ave a pair 
of Intel D-525MW boards running some cnc machinery, that must have the 
libgl-mesa-swx11 packages installed else no usb cameras actully work.

The lspci for the video is:
00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated 
Graphics Controller (rev 02)

An i915 based setup i believe.  Using the gfx driver that comes with the 
2.6.32-122-rtai kernel, the only one we can presently run on these realtime 
controlling machines.

But an accessory piece of software for these applications must have the std 
libgl stuff installed or it won't compile.

But when I install that long enough to build halio.c, then revert to the 
libgl-mesa-swx11 stuff so the cameras work, the resultant miss-match makes 
halio spit out this error and die:

** (camview-emc-float.py:1930): WARNING **: 
/usr/local/lib/camunits/halio.so: undefined symbol: gluOrtho2D

That is a single line in halio.c that looks like this:
gluOrtho2D(0,w, 0, h);

Where I believe the w and h are the dimensions of the overlay window 
describing all 4 corners.

Is there a compatible call for systems that are forced to use the libgl-
mesa-swx11 stuff in place of the non swx11 versions?  Something I could 
edit into this file, and then build it while running the swx11-dev versions 
of all this?

Thank you very much for any assistance.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

Breeding rabbits is a hare raising experience.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Probably OT question, but it is video related

[Gene Heskett]

On Monday 18 November 2013 19:57:36 Gene Heskett did opine:

> On Monday 18 November 2013 18:54:38 Tormod Volden did opine:
> > On Mon, Nov 18, 2013 at 11:55 PM, Gene Heskett wrote:
> > > I just pulled this camera out of the mailbox, intending to use it on
> > > my milling machine for machine vision purposes.
> > > 
> > > (from hwinfo)
> > 
> > 
> > 
> > > But cheese cannot find it.  What am I missing please?
> > 
> > Try running lsusb -v on it and see if it lists video streaming
> > interfaces. Does it show up under /sys/class/video4linux ?
> 
I forgot to check, no, that tree does not exist according to an ls.

Thanks Tormod.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

Computer programmers do it byte by byte.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Probably OT question, but it is video related

[Gene Heskett]

On Monday 18 November 2013 18:54:38 Tormod Volden did opine:

> On Mon, Nov 18, 2013 at 11:55 PM, Gene Heskett wrote:
> > I just pulled this camera out of the mailbox, intending to use it on
> > my milling machine for machine vision purposes.
> > 
> > (from hwinfo)
> 
> 
> 
> > But cheese cannot find it.  What am I missing please?
> 
> Try running lsusb -v on it and see if it lists video streaming
> interfaces. Does it show up under /sys/class/video4linux ?

That is what it is sold as, its actually a Chinese endoscope, and actually 
looks as it it would be quite usable as such, 2 meter cord, leds in the 
head, and only 7mm in diameter, I can mount it on the spindle carrier not 
more than 1.75" from the spindle centerline.

But lets see what a lsusb -v says:  Vyyy lengthy

Bus 002 Device 025: ID 058f:5608 Alcor Micro Corp. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 ?
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  idVendor   0x058f Alcor Micro Corp.
  idProduct  0x5608 
  bcdDevice0.03
  iManufacturer   3 Alcor Micro, Corp.
  iProduct1 USB 2.0 PC Camera
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  407
bNumInterfaces  2
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  200mA
Interface Association:
  bLength 8
  bDescriptorType11
  bFirstInterface 0
  bInterfaceCount 2
  bFunctionClass 14 Video
  bFunctionSubClass   3 Video Interface Collection
  bFunctionProtocol   0 
  iFunction   1 USB 2.0 PC Camera
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass14 Video
  bInterfaceSubClass  1 Video Control
  bInterfaceProtocol  0 
  iInterface  1 USB 2.0 PC Camera
  VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype  1 (HEADER)
bcdUVC   1.00
wTotalLength   85
dwClockFrequency   30.00MHz
bInCollection   1
baInterfaceNr( 0)   1
  VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype  2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType  0x0201 Camera Sensor
bAssocTerminal  0
iTerminal   0 
wObjectiveFocalLengthMin  0
wObjectiveFocalLengthMax  0
wOcularFocalLength0
bControlSize  3
bmControls   0x
  VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType  0x0101 USB Streaming
bAssocTerminal  0
bSourceID   6
iTerminal   0 
  VideoControl Interface Descriptor:
bLength 7
bDescriptorType36
bDescriptorSubtype  4 (SELECTOR_UNIT)
bUnitID 4
bNrInPins   1
baSource( 0)1
iSelector   0 
  VideoControl Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype  5 (PROCESSING_UNIT)
  Warning: Descriptor too short
bUnitID 5
bSourceID   4
wMaxMultiplier  32208
bControlSize2
bmControls 0x157f
  Brightness
  Contrast
  Hue
  Saturation
  Sharpness
  Gamma
  White Balance Temperature
  Backlight Compensation
  Power Line Frequency
  White Balance Temperature, Auto
iProcessing 0 
bmVideoStandards 0x1b
  None
  NTSC - 525/60
  SECAM - 625/50
  NTSC - 625/50
  VideoControl Interface Descriptor:
bLength27
bDescriptorType36
bDescriptorSubtype  6 (EXTENSION_UNIT)
bUnitID 6
guidExtensionCode {564c97a7-7ea7-904b-8cbf-1c71ec303000}
bNumControl16
bNrPins 

Probably OT question, but it is video related

[Gene Heskett]

Greetings;

Ubuntu 10.04.4 LTS install here with a later PAE enable kernel running. 
3.8.2 it says.

I just pulled this camera out of the mailbox, intending to use it on my 
milling machine for machine vision purposes.

(from hwinfo)
81: USB 00.0:  Unclassified device
  [Created at usb.122]
  UDI: /org/freedesktop/Hal/devices/usb_device_58f_5608_noserial_if0
  Unique ID: xYUG.GE5vcJfA7L0
  Parent ID: 75L1.+Ut3GdH4A67
  SysFS ID: 
/devices/pci:00/:00:02.1/usb2/2-6/2-6.4/2-6.4.4/2-6.4.4:1.0
  SysFS BusID: 2-6.4.4:1.0
  Hardware Class: unknown
  Model: "Alcor Micro USB 2.0 PC Camera"
  Hotplug: USB
  Vendor: usb 0x058f "Alcor Micro Corp."
  Device: usb 0x5608 "USB 2.0 PC Camera"
  Revision: "0.03"
  Speed: 480 Mbps
  Module Alias: "usb:v058Fp5608d0003dcEFdsc02dp01ic0Eisc01ip00in00"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #79 (Hub)

But cheese cannot find it.  What am I missing please?

Thanks.


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

Some performers on television appear to be horrible people, but when
you finally get to know them in person, they turn out to be even worse.
-- Avery
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: Is this a framebuffer job?

[Gene Heskett]

On Thursday 07 November 2013 15:19:26 edgar did opine:

> Am Thu, 7 Nov 2013 13:26:14 -0500
> 
> schrieb Gene Heskett :
> > Hello all;
> > 
> > I, and several others are attempting to make use of camera vision in
> > a machine shop environment, to auto position a lathe or milling
> > machine for instance.
> > 
> > My current camera is the highest priced of the logitech webcams, with
> > a nominally 5 megapixel format.
> > 
> > But for our purposes, the field of view at 2540x19xx is at least 75
> > degrees.  We need maybe 5 degrees because all we are interested in is
> > the pixel under the center pixel of the crosshairs.  This, when
> > inspecting the workpiece from 50mm, should represent accuracy's in
> > the thousandth of an inch category, and would generally be quite
> > useful to us.
> > 
> > So, is it possible to setup a framebuffer with 2 circular pointers,
> > the input pointer writing the 5 megapixel image as it comes in, and
> > an output pointer that only reads out the central 100x100 pixels of
> > the image, maybe even 240x240 but for our uses its overkill.
> > 
> > The problem as it exists now is the processing time for the video
> > image to get thru camview-emc and actually be presented on our
> > computer screens, is on the order of 3 to 5 seconds when the whole
> > signal chain has to deal with the 2540x19xx format of a decent
> > webcam.  If we could throw away all but the mathematical central area
> > of the image that the rest of the video chain had to process using
> > only 1 core of a 1.4Ghz atom processor, it seems we could save many
> > valuable seconds of image processing time.
> > 
> > The V4L list didn't understand what I wanted, so everything they
> > suggested threw away resolution which we don't want to do, and gave
> > the same field of view in the output, but converted to useless fuzz.
> > Hence I come here in search of help.  Effectively, we need extreme
> > telephoto at maybe 57,600 pixels (240x240 for this example)
> > resolution, captured pixel by pixel from the central 57,600 pixels of
> > the input for this application.
> > 
> > Thank you for any usable suggestions.
> > 
> > Cheers, Gene
> 
> This is a job for a camera with a telephoto lens.
> You're using a camera with the wrong lens, that's all.

Several reasons not to.
1. Such lenses may be available where you are but just asking about them at 
stores where I can buy the camera gets me a "telewhat?"

2. Mechanical alignment, quite important, depends on the precision they use 
to mold the plastics.  And is generally non-repeatable.

3. Costs several times what the camera costs.

4, throwing away the unwanted pixels should be a few lines of code, 
essentially free, and by reducing the amount of data to be processed from 
5,000,000 pixels to 57,600 pixels gains me only .0868% times the data to 
process, which gains me many frames a second in processing speed, something 
your lens cannot not do.
> 
> For many cameras there are telephoto adaptors.

And how many can focus to 20mm from their front element?
 
> Capturing 2540x19xx pixels to get a 100x100 picture is
> an extremely unreasonable approach.
> 
Considering the cost of your alternative, its a most reasonable approach.
A run what ya brung approach to be sure, but if it gets the job done, who 
cares if I throw away roughly 95% of the picture?

Any body else?

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

"It's in process":
So wrapped up in red tape that the situation is almost hopeless.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Is this a framebuffer job?

[Gene Heskett]

Hello all;

I, and several others are attempting to make use of camera vision in a 
machine shop environment, to auto position a lathe or milling machine for 
instance.

My current camera is the highest priced of the logitech webcams, with a 
nominally 5 megapixel format.

But for our purposes, the field of view at 2540x19xx is at least 75 
degrees.  We need maybe 5 degrees because all we are interested in is the 
pixel under the center pixel of the crosshairs.  This, when inspecting the 
workpiece from 50mm, should represent accuracy's in the thousandth of an 
inch category, and would generally be quite useful to us.

So, is it possible to setup a framebuffer with 2 circular pointers, the 
input pointer writing the 5 megapixel image as it comes in, and an output 
pointer that only reads out the central 100x100 pixels of the image, maybe 
even 240x240 but for our uses its overkill.

The problem as it exists now is the processing time for the video image to 
get thru camview-emc and actually be presented on our computer screens, is 
on the order of 3 to 5 seconds when the whole signal chain has to deal with 
the 2540x19xx format of a decent webcam.  If we could throw away all but 
the mathematical central area of the image that the rest of the video chain 
had to process using only 1 core of a 1.4Ghz atom processor, it seems we 
could save many valuable seconds of image processing time.

The V4L list didn't understand what I wanted, so everything they suggested 
threw away resolution which we don't want to do, and gave the same field of 
view in the output, but converted to useless fuzz.  Hence I come here in 
search of help.  Effectively, we need extreme telephoto at maybe 57,600 
pixels (240x240 for this example) resolution, captured pixel by pixel from 
the central 57,600 pixels of the input for this application.

Thank you for any usable suggestions.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

  An Irishman is never at peace except when he's fighting.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: xorg-server 1.13.1, - checksum post-mortem

[Gene Heskett]

On Friday 04 January 2013 12:27:11 Alan Coopersmith did opine:
Message additions Copyright Friday 04 January 2013 by Gene Heskett

> On 01/ 4/13 04:48 AM, Gene Heskett wrote:
> > I'll 2nd that sentiment.  I have had several occasions where I
> > downloaded the bzip2 and had to go back and get the .gz because whole
> > directory trees were missing from the unpacked archive.  Once or
> > twice I have pulled the bzip2 a 2nd time, same md5sum, but the 2nd
> > time unpacked well enough to build.  A 2nd unpack of the first
> > download was still defective.
> > 
> > In short, bzip2 has not been 100% trustworthy here.
> 
> We always use the bzip2 archives for building our packages, and haven't
> hit any problems.  Since no one else reports any corrupted archives on
> the X.Org download sites, it sounds more likely a problem on your end.

I can count the problems on one hand Alan, so its well over 99% dependable, 
but not 100%, which was my point.  bzip2 has also had 3 or 4 updates since 
that time frame but I've done zero research to see if the reported reason 
for the updates was possibly related.

Thanks.


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views 
<http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml>
Win98 error 009: Erroneous error: Nothing is wrong.
I was taught to respect my elders, but its getting 
harder and harder to find any...
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com