Page 2 of 3

Re: inputattach

Posted: 04 Apr 2013, 19:41
by fanthom
here is "penmount over tslib" solution for 32bit porteus-2.0 (kernel 3.7.8 ):
http://www.mediafire.com/?jkuz9q3y636tgsw
(it wont work for other porteus versions)

archive contains 3 folders:
- src (all sources, extra patches, slackbuilds, etc)
- pkg (slackware packages created from sources
- xzm (one xzm bundle containing all packages)

i have strictly followed README file from pmLinux-tslib-Debian6-src archive but done it the "slackware way" (sysvinit script instead of rc.local and script in /etc/profile.d instead of .bashrc - to make sure that original files wont be overriden by this module).

all what you need to do is to put penmount_over_tslib-alldeps-0.1-i486-1ftm.xzm (from xzm folder) to /porteus/modules and reboot.
make sure you boot with 'vga=791' (or whatever) parameter as according to README:

Code: Select all

Some of the utilities such as ts_calibrate uses framebuffer device for display, the default is /dev/fb0.
good luck!

btw: if this solution wont work then i'm giving up :)

Re: inputattach

Posted: 04 Apr 2013, 20:17
by quotaholic
I seriously appreciate the efforts. I got an invalid mode -pm on module load. Seems inputattach likes your computer but not my own. Oh well. Please do throw in the towel. I should have checked one other thing early on.... hard buttons....

All is lost without that atlas_btn kernel module. Porteus 2.0 does not have it either. If I had better success making my own kernel in the past from /tutoriels/kernel I would try again.

Thank you for all of your help!

quotaholic from webdt.org

Re: inputattach

Posted: 04 Apr 2013, 20:42
by fanthom
i have run 'inputattach --help' and could not find '-pm' as a valid mode.
supported modes are:

Code: Select all

--penmount9000   -pm9k     PenMount 9000 touchscreen
  --penmount6000   -pm6k     PenMount 6000 touchscreen
  --penmount3000   -pm3k     PenMount 3000 touchscreen
  --penmount6250   -pmm1     PenMount 6250 touchscreen

so i think you should remaster my xzm module and edit /etc/rc.d/rc.4d/S-penmount script as follows:

Code: Select all

inputattach -pm9k /dev/ttyS0 &

Re: inputattach

Posted: 04 Apr 2013, 21:11
by quotaholic
I am so jealous that you have a working inputattach on your computer. I left XFCE 2.0 on the thumbdrive and plugged it in to a laptop and just booted for reference.
root@porteus:~# inputattach --help

Usage: inputttach <mode> <device>

Modes:
--sunkbd -skb Sun Type 4 and Type 5 keyboards
--spaceorb -orb SpaceOrb 360 / SpaceBall Avenger
--spaceball -sbl SpaceBall 2003 / 3003 / 4000 FLX
--magellan -mag Magellan / SpaceMouse
--warrior -war WingMan Warrior
--stinger -stng Gravis Stinger
--mousesystems -msc 3-button Mouse Systems mice
--sunmouse -sun 3-button Sun mice
--microsoft -bare 2-button Microsoft mice
--mshack -ms 3-button mice in Microsoft mode
--mouseman -mman 3-button Logitech and Genius mice
--intellimouse -ms3 Microsoft IntelliMouse
--mmwheel -mmw Logitech mice with 4-5 buttons or wheel
--iforce -ifor I-Force joysticks and wheels
--h3600ts -ipaq Ipaq h3600 touchscreen
--stowawaykbd -ipaqkbd Stowaway keyboard
--ps2serkbd -ps2ser PS/2 via serial keyboard

root@porteus:~#
and
root@porteus:~# inputattach -pm9k
inputattach: invalid mode
Are you on 64 bit? Why would this return different results on your computer if we are working from the same image?

Re: inputattach

Posted: 04 Apr 2013, 21:24
by fanthom
please show me output of following command:

Code: Select all

/mnt/live/memory/images/penmount_over_tslib-alldeps-0.1-i486-1ftm.xzm/usr/bin/inputattach --help
if you get correct output then please boot without 'changes=' cheatcode (your custom inputattach from changes may override one from my module).

btw: kernel recompilation is quite easy. please follow my guide "word by word".

Re: inputattach

Posted: 04 Apr 2013, 23:59
by quotaholic
I am getting somewhere. X wont start up. Just flashes until 5min timeout hits. Honestly that is almost enough time to debug. How do I disable the damon that is always trying to startx?

In between flashes I can see enough to get in to /var/log/Xorg.0.log. I see tslib take the penmount over and that is good. Sadly shortly after x segfaults. I try to adjust .conf and other files but then x tries to start and my work gets crushed. Is there a simple way to disable this "feature"?

Re: inputattach

Posted: 05 Apr 2013, 10:24
by fanthom
please do as follows:
- boot to text mode
- login as root and run 'xconf' command
- run 'startx' manually (in case of Xorg failure press 'ctrl+alt+backspace' to kill xserver)
- if you get a failure then please run: 'cp -a /etc/X11/xorg.conf-vesa /etc/X11/xorg.conf' and run 'startx' again.
- if you still get a failure then you could try to compile xf86-video-fbdev driver (framebuffer driver for Xorg). not sure if it's better than VESA but worth trying.

good luck!

Re: inputattach

Posted: 14 Apr 2013, 02:44
by quotaholic
Interesting lead at the end there. I remember tslibs saying it needed a /dev/fb0 to aim at so I compiled fbdev and watched a few days worth of segfaults no mater what I tried. X will work on vesa driver but not tslib. I just get segfaults.

I wiped the drive clean and since I need to rebuild the kernel I started fresh and am watching a kernel build as I type. I have atlas buttons and penmount in there as well as some other hardware specific items. When this finishes in the morning I am going to be ready to repack the 000-kernel.xzm and the initrd. Two questions.

A long time ago in slackware we used to be able to gzip the kernel modules and the slackware kernel would still load and use them. In theory since this kernel supports .xz compression can we compress the kernel modules before repacking in xz compression to save a little space?

Two: I read ahead in the documentation and I see instructions on packing an initrd for pxe booting. Will this also suffice for a how to on a normal initrd? Or will the pxe version work for both pxe and non pxe booting?

Thanks in advance
quotaholic

Re: inputattach

Posted: 14 Apr 2013, 07:41
by fanthom
I remember tslibs saying it needed a /dev/fb0 to aim at so I compiled fbdev and watched a few days worth of segfaults no mater what I tried. X will work on vesa driver but not tslib. I just get segfaults.
framebuffer device (/dev/fb0) is created once you boot with 'vga=791' (or other value) cheatcode. please make sure that you are booting with such cheatcode and that it has a correct value.
in case of further troubles please provide /var/log/messages and /var/log/Xorg.0.log and i'll have a look on them.
A long time ago in slackware we used to be able to gzip the kernel modules and the slackware kernel would still load and use them. In theory since this kernel supports .xz compression can we compress the kernel modules before repacking in xz compression to save a little space?
no point for compressing kernel modules separately as 000-kernel and initrd are both compressed with xz anyway (it would be like zip archive containing several other zip archives inside)
I read ahead in the documentation and I see instructions on packing an initrd for pxe booting. Will this also suffice for a how to on a normal initrd?
in porteus-2.0 we have separate initrd for pxe booting (/boot/syslinux/pxelinux.cfg/initrdpxe.xz) and only this initrd should be updated with new drivers (and only if you care about pxe boot).
main initrd (/boot/syslinux/initrd.xz) does not contain any drivers itself so can be skipped.
in case of adding extra drivers to main initrd (like scsi, btrfs, etc) the procedure for unpacking/re-packing is the same.

Re: inputattach

Posted: 14 Apr 2013, 18:42
by quotaholic
If I dont put vga=771 on the boot line these tablets wont start up so that is a given. As Porteus kernel was not built with uinput module enabled my fallback of eGalax driver was not possible. So I wiped drive and had to start over. /misc/x86/atlas_btns had to be enabled too.

Watching another kernel build. This time 3.4.9 on Porteus 1.2. Last build was also on 1.2 but with 3.4.4. Xorg.0.log pointed towards glibc segfault anytime I used tslibs as penmount driver. Workaround of eGalax driver was not possible so I took two steps back to move to 3.4.9 and build in needed options.

We did get the serial /dev/ttyS0 to report to /dev/input/event5 however linking to tslibs was another story. I cat a bunch of log files and >> to txt files in home directory then remastered iso on my old build. If I mount in loop for some reason txt files are not there otherwise I would share. I will do better job keeping log files accessible on this build should problems exist.

Re: inputattach

Posted: 16 Apr 2013, 18:31
by quotaholic
Several swings and several misses. On try number 4 I was able to get past kernel panic and was booted to a shell once a porteus sgn file was not found. I found a ton of stuff that the kernel had for this hardware. Just had to get a AMD Geode data sheet out. Found the old pata cs5520 and all the old alix stuff. I see your point on slax 6.1.2 more now. Compile time on 3.4.9 is over 7 hours a shot. Not sure how to debug my current situation with the sgn file. I saw /dev/ram0 load a ext4 on device 1:0 but no block devices are found in the shell that is resulted.

I tried rebuilding slax kernel but only put a little effort to it. I know that my folder structure was out of context for the script. Possibly I will put effort more to that today. Need atlas_btns. Curiously I installed slackware 14 on a laptop and altas_btns as well as uinput is enabled in 3.2.9 kernel by default. This means hard buttons on front and side of tablet will work (http://aprsisce.wdfiles.com/local--file ... rch366.jpg), as well as having a fallback for eGalax touch screen driver.

Sadly the hard drive on tablets is ~500mb. This is why Porteus is 99 percent the perfect operating system. I love the documentation and thank you for holding my hand through my efforts however the time needed to make such small changes to Porteus is more than I have. I just started a new job and will not have the needed blocks of time very often. Lots of these on ebay... DT research, the manufacturer, cycles end of life every 5 years or so. This puts a lot of industrial "rugged" tablets in the surplus markets.

My skills are home automation and industrial automation. Sadly both markets have been unstable enough to keep me from eating three meals a day for a long time now. This effort I am taking on is to honor the person who paid for my (webdt.org) hosting bills as I was unable. I wanted to thank him by providing a persitent live disto that worked on the hardware. If anyone wanted to help out I cant tell you how much you would be doing for linux users everywhere. A 100 dollar tablet that you can hack away upon? Not sure how popular the Kiosk version is but if someone made a webdt version I am pretty sure it would be very well received. I would offer to send a tablet to anyone who would embark upon such an effort only I can not pay for shipping at this time.

I have a .config file for anyone who asks for it.

If not I will continue on this effort as soon as I can make the time.

Thank you in advance
quotaholic

Re: inputattach

Posted: 16 Apr 2013, 19:20
by fanthom
please tell me exac kernel config options you want enabled (one by one, please avoid mistakes) and the kernel version (3.2.x, 3.4.x, latest) and i'll compile it for you.
kernel options should be listed in a form of ie:

Code: Select all

CONFIG_CLZ_TAB=y
as i want to make sure i compile the right kernel (wont have the time to do it again).

Cheers

EDIT:\\
please also state porteus version it will be used.

Re: inputattach

Posted: 16 Apr 2013, 19:34
by quotaholic
Here is my .config file:

a result of make menuconfig

config:
http://pastebin.com/5Qx9XMq7

Fanthom you are my hero! Once I am on my feet I will make sure that you have a tablet.
thank you so much!

quotaholic

PS I think this is a good config. Please look over fs and block devices as I am not sure. I enabled ext4 and forgot to tick large file on build three. I enabled large file and more fs on this (#4) config.

This is on Porteus 1.2 with upgraded 3.4.9 kernel.

Re: inputattach

Posted: 16 Apr 2013, 21:08
by fanthom
i see that this config was strictly profiled on specific hardware (although i see some inconsistencies, wont change them just in case as i know nothing about the target hw) so want to be sure:
will porteus be booted from usb only or CD and hard drives as well?
if CD/hd as well then please provide specific controller names otherwise i'll have to compile everything in.

Re: inputattach

Posted: 16 Apr 2013, 22:56
by quotaholic
Hi Fanthom,
Let me look over config at porteus section. I will look for unanswered questions.

I plan on installing from usb to hard drive. Either through porteus installer or via a live distro.

For the life of the units we plan on booting from the internal pata 44pin ide DOM / ssd. The controller is a:

IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01)

taken from lspci

Get back to you with the config asa

EDIT/

New config:

http://pastebin.com/XASC3Z6b

Saw that I missed a cross compile question in quotes. Hopefully that was it. Some questions are commented out as a result of what carried in from original "make oldconfig". Looking at text version even commented out questions are answered s:

CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y

just above

# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(WebDT)"
CONFIG_SWAP=n



Yes this is platform specific. If nothing else fails it should be a very small kernel that will fit well in the 512mb of ram and enable functionality that has not been available for a while on this platform.

Please let me know if I missed anything