Week 7 report:
- ADK driver: ADB +ADK working: ADB over Wifi is now working for logs
while in ADK mode
- ADK driver: Testing with test data from sent from userspace - test
data is generated in kernel space earlier
- Android app: Fixed fc on opening w/o accessory attached.
- Android app: Added accessory connection status, read values and
write options in the app UI
- Framebuffer: Added android device as DisplayLink device for
Framebuffer. Probing works now, only on the interface of interest - No
duplicate probing issue.
- Framebuffer: Updated endpoint address for BULK writes to device. Now working.
- Framebuffer: Logged raw initialization sequence data sent by the
framebuffer to DisplayLink devices on the Android device. Will be
analyzing this for future work. Can be seen in the image attached.
- FB data interpretation: The meaning of the initialization sequence
data from framebuffer is not clear. Also the encoding of the data
might be needed. Not sure if it is UTF8 encoded right now.
- FB Triggers: It is unclear as of yet if there is a need for another
module or userspace code which should be issuing the triggers for
sending updated frames from udlfb driver. Right now the driver isn't
doing any work after the probe function.
- Android app: A couple of FCs when the device is detached from ADK
mode. Should not be a big issue. Can be fixed easily.
Plans for next week:
- Interpretation of the data sent from the FB driver in the
initialization sequence only if that happens to affect the working of
a basic version.
- Finding out how the continuous frame updation part works in the
driver. May be a need for external module?
- If the above two goes well, try to interpret the frame data and see
if we can get an image on the Android device. udlfb uses run length
encoding on the frame data sent to a DisplayLink device.
This report is also available with updates through the week at