**** BEGIN LOGGING AT Sun May 03 03:00:00 2015 May 03 06:47:37 * Abhishek_ moves in to Banglaore May 03 18:48:39 Tartarus: finally got the usb booting thing to work on OS X and windows May 03 18:49:42 nice May 03 18:50:45 needed some simple RNDIS init messages...on Linux the module was doing that for me and I was unloading it afterwards. on osx there was nobody to do that May 03 21:04:57 arianepaola: i pushed all the OS X code into https://github.com/ungureanuvladvictor/BBBlfs/tree/osx. there is a folder called codeless_kext which has a working codeless kext. now we need to sign it. May 03 23:25:01 praveendat92: ping May 03 23:25:20 praveendath92: ping May 03 23:25:31 azizulhakim: pong May 03 23:26:06 hi, can you tell me the video transfer rate performance you experienced in the udlfb driver? May 03 23:26:31 in my case i see its not very good for playing some low resolution video May 03 23:26:46 looks like bandwidth is an issue May 03 23:27:03 azizulhakim: That's true. May 03 23:27:15 It's due to lack of compression. May 03 23:28:03 ok. but you mentioned compression also adds lot of burdent mostly in android side May 03 23:28:04 I implemented RLE compression but it was consuming too much CPU load so I stopped using compression. May 03 23:28:04 right? May 03 23:28:12 ok May 03 23:28:28 I'm guessing it can be fixed. May 03 23:28:38 I might have done something wrong with compression. May 03 23:29:07 The Order of encoding and decoding is N - in number of bytes but... May 03 23:29:19 I think it can be improved. May 03 23:29:37 Ideally, bandwidth shouldn' May 03 23:29:50 I see. Okay. I'll keep this in focus. May 03 23:29:54 shouldn't be an issue since DisplayLink is able to do it well. May 03 23:30:09 it's usb2.0 it should work really well May 03 23:30:18 BTW, you can look at the RLE implementation by DisplayLink guys. May 03 23:30:26 Did they apply any compression? May 03 23:30:33 Oh so they did RLE also May 03 23:30:50 Yes. I didn't quite get the implementation so.. May 03 23:30:55 Can you give me the source repository please May 03 23:31:00 I decided to implement it. May 03 23:31:08 Just a sec/ May 03 23:32:18 https://github.com/praveendath92/bard-linux/tree/1c99a1605337fdd94c782f1bc0fb61139ace983d May 03 23:32:30 Taken from commit history. May 03 23:33:15 Ok thanks May 03 23:33:20 Anytime. May 03 23:33:26 I also have one issue in case you have any idea May 03 23:33:33 I can try. May 03 23:33:45 Suppose I'm sending 4096 bytes of packet from the driver May 03 23:34:06 And in android side I want to read that with two read operation. Say half in one read May 03 23:34:19 But that doesn't work. I've to read the full chunk at a time May 03 23:34:26 Ever faced that? May 03 23:34:49 Yes. That's another problem May 03 23:35:05 Everything is read in 512B actually. May 03 23:35:19 Any higher number is just cached by android system. May 03 23:36:19 What if I have lower number? May 03 23:36:32 Min. is 64B May 03 23:36:57 Also if I try to read by 2048 bytes, its still higher than 512 May 03 23:37:18 The problem with the API on Android side is that... May 03 23:37:33 You need to specify the length of buffer you are expecting to read. May 03 23:37:55 And Android waits until that length of data is sent from the other side and then passes it. May 03 23:37:55 praveendath92: that is expected, the result of the call is the actual lenght if i remmber right May 03 23:38:33 Yes. True. May 03 23:38:59 So, longer lengths imply more work on Android to give you big packets. May 03 23:39:14 But then small packets will have to wait until buffer is full. May 03 23:39:45 another idea is if we can use libusb and call methods from there. May 03 23:39:51 I think I have a solution here. May 03 23:39:55 libusb has some asyc calls which have a callback assigned to them May 03 23:40:10 libusb on Android side? May 03 23:40:33 yes, you can open the fd from java and pass it to libusb JNI May 03 23:40:46 Oh. That might work. May 03 23:40:57 i do not know if you need root or no May 03 23:41:04 I think I wasn't able to put my question properly. I know I've to give the length of data I want to read and android will wait until it receives that amount. May 03 23:41:30 from the driver side I am sending 4096 bytes for example May 03 23:41:57 and in android side I do two read like read(2048) read(2048) May 03 23:42:29 so I was expecting after it is done with 1st read, it'll move to 2nd read May 03 23:42:46 Do you get failures on Bone? May 03 23:42:56 With lower values for data sent? May 03 23:43:03 but what I see is it gets halt in the first read. and the driver throws -101 or some other error I don't remember now May 03 23:43:35 Error code would help a lot here. May 03 23:44:05 I have some issues related to this. May 03 23:44:14 Probably not the exact same ones. May 03 23:44:30 most possibly it was EPROTO error. May 03 23:45:12 71? May 03 23:45:36 101 is ENETUNREACH May 03 23:45:41 That makes sense too. May 03 23:45:55 May be. I've seen both 71 and 101 a lot of times. May 03 23:46:10 Then it was 71 I guess May 03 23:47:06 As soon as Android received enough data receiver is expecting, it would return the data to caller and until you start another read wait request no data can be sent to Android. May 03 23:47:29 Since the protocol is blocking on both sides. May 03 23:48:15 So after reading half your data, the listener on Android exited abruptly to go into processing. May 03 23:49:09 And I'm guessing that's how kernel handles when a pipe is closed or unavailable during the transfer. May 03 23:49:36 Hmm. That makes sense. May 03 23:50:29 I suggest that you use additional buffers to break every data into quantum of small packets... May 03 23:50:39 and use this quanta on both devices. May 03 23:51:02 That way you can handle large and small transfers w/o failures. May 03 23:51:25 Right. May be I'll have to do that May 03 23:51:38 Since you are using one more buffer management in your application, you will have better control again. May 03 23:52:32 Actually that was also part of the USP protocol I was bothering you with :P May 03 23:53:38 Also... May 03 23:53:43 Yes, I was thinking about that. Right now I'm just doing some experiment on multiple scenario and trying to compare the results. May 03 23:53:54 Oh. That's nice :) May 03 23:54:35 One of the main reasons for pushing for individual modules is that user can load or unload some functionality at run time. May 03 23:55:47 Didn't think about that. Great idea. May 03 23:56:01 ...and the unstated fact that I tend to be intimidated by large codes :P May 03 23:56:03 It'll give more flexibility to users May 03 23:56:17 Yep. May 03 23:56:18 :p May 03 23:56:59 So, I spoke to Abhishek_ a while ago about the performance. May 03 23:57:10 I thought I was the only one. May 03 23:57:45 Since Linux kernel and it's modules run in single address space, there should be no perf, effect. May 03 23:58:28 Because you are just calling a diff. fn from other module to do the transfer for you and just like what you do now.... May 03 23:58:54 You pass pointer to the data and length. You do NOT have to copy the data so. May 03 23:59:56 azizulhakim: FYI http://www.virtsync.com/c-error-codes-include-errno May 04 00:00:44 thanks May 04 00:01:22 The RLE code that you give, is that your implementation or displaylinks implementation? May 04 00:01:47 The link I sent from commit history? That's DisplayLinks. May 04 00:02:26 okay May 04 00:02:43 I didn't fully understand their entire code but I theoretically my code should work better :o May 04 00:03:31 They are doing adjacent byte comparisons while I compared adjacent pixel values (2 bytes). May 04 00:03:53 So once you do RLE it will change the length of the data. Right? May 04 00:04:06 Since pixel is the unit of info for display I think mine should work better but well, no the case. May 04 00:04:12 Yep. May 04 00:04:26 Can be any length. May 04 00:04:35 Depending on the image. May 04 00:05:21 And the data length will be variable. So how did you catch this variable data from android side? Sending length in one chunk and actual data in another chunk? May 04 00:05:29 The way I see it, you are going to have to implement so many producers and consumers :D May 04 00:06:02 I had YPOS|LEN|DATA May 04 00:06:58 The problem is that transfer unit size can't be 2050 or whatever. May 04 00:07:41 And since kernel sends packets of different sizes, you would run into the issue you mentioned earlier. May 04 00:08:29 The way I see it, fix a transfer packet size. May 04 00:08:43 Implement another buffer in the application. May 04 00:09:32 hmm May 04 00:24:54 praveendath92: have you ever been able to test it in pc? I was never been able to do that. Each time I execute the XServer it just creates a new X window on the computer, not on android display. May 04 00:26:14 I mostly got a crash when ever I test it with PC. May 04 00:26:43 I don't remember if I saw a display on Android because it crashed eventually. May 04 00:27:05 Oh wait. I remember getting X terminal on both devices. May 04 00:27:20 Yep. I definitely did get that. May 04 00:27:28 Same happened to me before. But yesterday I tested inside a VM and there was no crash at all. Each time it just created a new X Window inside the VM May 04 00:27:45 Seems like there is some dependency issue May 04 00:28:01 azizulhakim: you are running host windows then VM with linux ? May 04 00:28:12 That's odd! May 04 00:28:24 Not running Linux in Windows. May 04 00:28:54 vvu; No. Both host and guest are linux. May 04 00:29:37 Before I was having crash issues in Ubuntu 13.10. Recently I installed Ubuntu 14.04. No crash there. X throws some error messages and exits. No crash. May 04 00:29:37 Good news is VM doesn't crash. May 04 00:30:01 On VM, do you see any errors in the log? May 04 00:30:05 Inside VM X runs well, no crash, and creates a new X window May 04 00:30:32 But not shown on Android? May 04 00:31:28 Not show on android. From log it seems it opens the framebuffer and then instantly release it and control moves to the VM again May 04 00:32:28 when you open the fb you do something usb related ? May 04 00:32:43 maybe android gets confused host/guest May 04 00:34:01 I don't do anything usb related. May 04 00:34:42 But a new fb is created by the driver inside the VM? May 04 00:35:56 Yes, new fb is created. May 04 00:36:36 Then Android should be communicating with VM. May 04 00:37:33 This is odd. I will try this from my side and see if I can get something out of it. May 04 00:37:49 http://pastebin.com/4nVgh1Ed May 04 00:37:58 take a look at this log May 04 00:38:08 its from a successful run in bone May 04 00:38:38 Note that at the very beginning it opens the fb, releases the fb, and then again open it and starts operation May 04 00:39:09 In VM it opens the fb, releases it and then something may goes wrong May 04 00:41:04 Thanks for the log. May 04 00:41:54 I haven't figured out why that's happening but I will look at the code. May 04 00:42:08 It's been a long time since I touched the display driver. May 04 00:45:40 Sorry, my VM is also 13.10 with kernel-3.11.0-12-generic May 04 00:54:28 I don't know why that should be a problem. May 04 00:54:55 Do let me know if it worked with 14.04 VM. **** ENDING LOGGING AT Mon May 04 02:59:59 2015