This page describe my limited knowledge on the Webtop based on Razr.
One of the most embarrassing moment is that when the Webtop phone view is blank or absent. Or any other thing that made the Webtop have a need of restart. In general, restarting the processes related to Webtop will fix this.
To restart the Webtop:
/etc/init.d/webtop-restart.sh
To shutdown the Webtop and let it auto start the associated processes on next Webtop mode activation:
/etc/init.d/webtop-shutdown.sh
In fact the phone view process is controlled by the aiw. So you could simply find the pid of aiw and kill it. If there is a process 'sfalv i aiw -d' then the aiw process will be started automatically. I guess sfalv is something like a process wrapper that will re-spawn the process automatically when it is being killed.
To run any Webtop related command, most likely we need to do this first:
# /usr/bin/sudo -u adas -i
Then a proper shell will be spawned and commands like evbridge and aiw will work. This is learnt from the /etc/init.d/startX.sh script.
Okay the official name should be track pad. Why? See /usr/local/share/motorola/trackpad ! The images for the track pad are there.
It's native process is in /usr/local/bin/evbridge (event bridge?). It is invoked from /usr/local/bin/start-oshwt-2.sh invoked from /usr/local/bin/webdaemon invoked from /usr/local/bin/start-oshwt-1.sh invoked from /etc/init.d/startX.sh.
/etc/init.d/rc.local is the startup script that responsible for loading the aev, evfwd and setting the following to allow read/write from the user adas:
/sys/devices/platform/evfwd/keys
/sys/devices/platform/evfwdrel/coordinates
/sys/devices/platform/aev/abs
These are one of the important thing to allow the track pad to work because evbridge will need to read/write from these files while translating and forwarding the events.
When the phone boot, it follows the Android init script /init.mapphone_umts.rc.
On dev.bootcomplete=1, /ubuntu.sh is invoked:
/usr/local/bin/ubuntu1.sh &
/etc/init.d/startXServer.sh &
/etc/rc.local
insmod aev
insmod evfwd
insmod gfx_vout_mod
chmod and chown to allow adas r/w:
/sys/devices/platform/evfwd/keys
/sys/devices/platform/evfwdrel/coordinates
/sys/devices/platform/aev/abs
On sys.SystemMode=RM_SM_DOCKED, /etc/init.d/startX.sh is invoked:
if /usr/bin/X not running
/etc/init.d/webtop-restart.sh
sudo -u adas -i /usr/bin/startx /usr/local/bin/xnull -- -nolisten tcp vt2 &
else
if metacity is not running
sudo -u adas -i /usr/local/bin/start-oshwt-1.sh &
end if
end if
When the Webtop mode is selected, sys.SystemMode will be set to RM_SM_DOCKED by PortalService. It is inspected that if the /usr/bin/X process is not running, sys.SystemMode will be set to RM_SM_DOCKED one more time such that the start-oshwt-1.sh can be invoked even if the first run of startX.sh run to the route of startx.
For the actual flow of how these happens, PortalService needs to be reviewed in-depth together with the logcat log.
As seen from /var/log/Xorg.0.log, the aev and evfwd virtual devices are added by xinput. The former is created from the kernel module aev.ko and the later is created from the evfwd.ko. aev(Android event?) is responsible for handling the events in the "phone view" windows. evfwd(event forwarder?) is responsible for receiving the touch and virtual key events of the track pad so that they can be forwarded to the X.
By experiments and guesses, this process reads touch events from /dev/webtop/input/event4 and translates to /dev/webtop/input/event8. However, evbridge needs to access to some of the sysfs created by evfwd. Thus if the evfwd module is unloaded and loaded again after the bootstrap is over, those access right has to be set manually correctly for the whole event chain to work again.
Several things can be checked for phones that have the event chain broken issue:
Whether evbridge is receiving touch events; (cat the respective event device file while touching the phone's screen)
Whether evbridge is translating and forwarding the events properly; (Manually submitting the events to the device file)
Whether the X sees the virtual devices and process events from them. (Use xinput list -l)
At first, I just have a Razr which is running Webtop 2.0 to perform differential analysis against Photon 4G which is running Webtop 1.0. (Thanks to my2cents on xda for setting up the environment for my remote investigation) Later with the help of Luminary(Zxo0oxz on xda) whom have Atrix to obtain the related information on Atrix, I can confirm that there is something wrong with the Photon. The following are the summary of the investigation of the unresponsive track pad issue:
The Xorg.0.log has no trace of aev and evfwd.
/dev/input/by-id/touchscreen is missing (the path has been changed in Razr)
lshal has fewer entry for evfwd.
No hald-addon-input process listening on the various /dev/input/event* .
After installing the cracked PortalApp and DockService, clearing the related dalvik-cache and rebooting, all of the 4 points above doesn't hold anymore. As expected, the track pad became functional.
However, another reboot just repeat the first scenario - unresponsive track pad.
One of the visible difference is the by-id path, it's creation time is a little bit later than the kernel boot time. Thus, it could be created by user space process that was initiated from the init script.
Finally, there is something about by-id in /etc/udev/rules.d/*, which is a folder read by /sbin/udevd.
/osh/etc/udev/rules.d # cat 90-local-touchscreen.rules
# create symlink for touchscreen
SUBSYSTEM=="input", SUBSYSTEMS=="input", ATTRS{name}=="qtouch-obp-ts", SYMLINK+="input/by-id/touchscreen"
SUBSYSTEM=="input", SUBSYSTEMS=="input", ATTRS{name}=="qtouch-touchscreen", SYMLINK+="input/by-id/touchscreen"
SUBSYSTEM=="input", SUBSYSTEMS=="input", ATTRS{name}=="cyttsp3-i2c", SYMLINK+="input/by-id/touchscreen"
SUBSYSTEM=="input", SUBSYSTEMS=="input", ATTRS{name}=="atmxt-i2c", SYMLINK+="input/by-id/touchscreen"
Obviously, the by-id/touchscreen symlink is created by udevd, which is started by /etc/init.d/udev, which is started by /init.mapphone_*.rc .
By trial and error, it is found that "/sbin/udevadm trigger --subsystem-match=input" is what created the /dev/webtop/input/ folder including the by-id one that is needed by evbridge.
More information about udev, hald and dbusd: http://blog.csdn.net/faithsws/article/details/5380710
Useful links for investigation:
http://elinux.org/Android_Booting