This post is a comprehensive view of a problem to get an MTP device to connect using MTP protocol so that Lighthouse64 can allow users to see all data contained on their smartPhones/smartTablets/smartDevices. This post outlines a problem specific to LH64 and ask/requests for your assistance in resolving.
Following was done to add MTP subsystem to LH64:
- Installed Tempestuous' 64 bit go-mtpfs package
- MTPconnect package
This is all that is required to add MTP support to a Puppy.
To see files contained on the smartDevice: Plugged Nexus 7 charging-data cable into LH64’s USB port. As is the case with 32bit PUPs tested, one expects a ROX window to open showing the Nexus 7’s filesystem and files. But, on LH64, nothing happened. I tried unplugging and plugging it in again, still nothing. Next;
- killed the MTPconnect process
- opened the console,
- started the MTPconnect process from the command line looking for messages or errors
No errors were generated. It simply wasn't detecting anything.
@Can8V ran his debug version, which is essentially the same script except that it has echo statements in every control point of the script, so that he can watch exactly what is going on while the script is running and see the value of variables at any given point. Running this script discovered that the script was monitoring fine, it just simply wasn't finding any product names or product IDs in the dmesg kernel ring buffer. To verify that it would in fact find a product id or product name in the dmesg kernel ring buffer should one actually exist he wrote a test message directly to the buffer with the following command:
Code: Select all
echo "product: Nexus_7 Product id: 4ee1" > /dev/kmsg
The monitor picked up the message and mounted the Nexus 7 in a fraction of a second, as can be seen in attached screenshot.
Next step took a look at the dmesg kernel ring buffer: Discovered two major problems:
- NONE of the entries have a timestamp
- There are simply no Product IDs or product names in the buffer, it is only recording "new device" and "device disconnected" with the associated USB port.
That information is far less than helpful.
Ideas ANYONE!
Does anyone know if there is any steps to get the kernel to report the necessary information to the dmesg kernel ring buffer
More Information
Since MTPconnect relies on the Kernel Ring Buffer and the dmesg command to be able to inspect the contents of said buffer, it is crucial that the kernel be appropriately configured to produce the necessary output to the buffer. If it does not do it then MTPconnect will not be able to find information in the buffer that does not exist, because the kernel failed to create it. Poking around was able to change the kernel parameters, so that it now outputs the timestamps to the kernel buffer ring. I accomplished that by setting the parameter at boot time by adding it as a kernel option in my Grub menu entry. See the following code:
Code: Select all
kernel /LHP64/vmlinuz psubdir=LHP64-515 pmedia=ataflash pfix=fsck pupmode=13 printk.time=1
There may be other kernel options I can set at boot time to get the kernel to print the Product name and Product ID instead of just reporting a "high speed device" has been connected or disconnected and the associated USB port. The screen shot below shows the kernel ring buffer displayed in the console using the dmesg command after rebooting the the printk.time=1 option added to the kernel option list in my grub menu entry. Notice that the timestamps are displayed and they are correctly showing seconds since boot. When this kernel was built, it appears to have NOT had this set, so, this option is turned off (set to 0 instead of 1).
There is a lot of information missing from the kernel ring buffer. At a minimum the timestamps need to be added to all entries in the buffer and somehow the entries that include each devices Product ID and name of the product need to be printed to the buffer. The timestamp option can be turned on at boot time as I described before. I don't know about the missing entries for the product ID and name. The product manufacturer ID is also missing from the buffer. While the Manufacturer ID entry was useful during development of MTPconnect, the application doesn't use the Manufacturer ID entry at all. Still this is another entry that should be in the buffer, but isn't.
This will need someone’s help to resolve the kernel settings so that LightHouse64 can identify the MTP devices attached where MTPconnect can properly post the devices use to the desktop. I personally am far from the most knowledgeable person when it comes to kernel options and compiling kernels, so for me to come up with a fix for this would require significant research, luck and time. Maybe somebody else already knows what to do.
Can anyone knowledgeable on kernel elements assist?
I did understand, back in the fall, that TaZoC was to undergo additional treatments, but, we have not heard from him in many months. Hope all is well with him.
Important NOTE! I am posting this to assist @Can8V because he is in school prepping for an exam ATM. This is an important item that could use some developer direction.
Here to help