Online Chess on FICS/ICC

[chessmoskito]

I think its quite to play online chess using Picochess and a Raspberry Pi - WITH NO PC, monitor and cable. Its just necessary to enter your name and Login Number ONCE - Using the clock buttons - just one Time and SAVE. After this you could define - and store your favourite seek wishes. For example:

seek r 1600-1800 20

And someone with elo 1600-1800 would accept and play a rated - 20 minutes game. It would be soooooooo cool. Can you make it?

[pablo2000]

Is this still a feature people are wanting?

I ask as I'm getting to the end of some hardware design work and about to start working on picochess again. I have a couple of other areas I want to look at, but was thinking of doing FICS/ICC play. It will be as a UCI 'engine', so will appear as another engine in the list to select, with username/prefs etc in a config file, so no need for PC. Details still to work out, but just wondering if anybody else is wanting this?

Pablo

[LocutusOfPenguin]

I guess, all this stuff ("play online at chess server" or "play remote")...Is a killer feature for picochess. Esp, when no PC is needed. Even noone active(!) asking for it.

This "remote play" mode still missing its function ;-) Jürgen

[ifekali]

Not only connecting to remote servers, user should be able to play against anybody with a web browser! This way user would simply give a friend an URL, web interface opens and remote friend can play against user!

This way no usernames or accounts on remote servers are needed. Simply give your URL and remote friend connects to your picochess via web interface! (of course, appropriate port should be routet to the raspberry)

On 11. sep. 2015, at 11.33, Jürgen Précour notifications@github.com wrote:

I guess, all this stuff ("play online at chess server" or "play remote")...Is a killer feature for picochess. Esp, when no PC is needed. Even noone active(!) asking for it.

• Jonas Žnidaršič jonas@jonas.si

[LocutusOfPenguin]

hi jonas,

what y saying is #22 (=remote play). I find this alot more important as "play over a chess server" and also easier to implement. see: Connect to a server is only half of job. Then, how to send/accept/watch...all the stuff the server offers? All this function is better done with a (fics) client which also supports the dgt-board.

And since we have this menu already [for long], its just waiting for someone to implement it ;-) Nevertheless, fics support is - im sure - a reason to buy the dgt board...but is it a picochess feature?

[ifekali]

Exactly!

On 11. sep. 2015, at 15.51, Jürgen Précour notifications@github.com wrote:

I find this alot more important as "play over a chess server" and also easier to implement.

• Jonas Žnidaršič jonas@jonas.si

[djdekker]

You're very right Jürgen. There are FICS/ICC/Playchess clients out there with DGT support, for example Babaschess or Fritz. Unfortunately though, these don't seem to work on Raspberry Pi (Windows only). So what's needed is a Raspbian version of Babaschess rather than a FICS/ICC update to Picochess.

[sshivaji]

Actually,

I second Jonas on this. We have a webserver. It is not hard to make collaborate analysis and analysis sharing. FICS does not have this support. With DGT boards and the web server, we are very close to making remote mode work.

I started this feature but I am now distracted with debugging picochess core issues in recent images. Once we have that working very well, I think remote mode would be fantastic.

Let me give you a very simple example. I can share the position I am looking over my dgt board to many people. Currently, one can transmit games while playing vs the comp and users from the internet can see how well you are doing (or how badly you are being beaten). Users can add in lines and suggestions. However, it would be cool if you can communicate with users on the internet too and thats what remote mode can do.

Shiv

— Sent from Mailbox

On Fri, Sep 11, 2015 at 11:01 AM, DJ Dekker notifications@github.com wrote:

You're very right Jürgen. There are FICS/ICC/Playchess clients out there with DGT support, for example Babaschess or Fritz. Unfortunately though, these don't seem to work on Raspberry Pi (Windows only). So what's needed is a Raspbian version of Babaschess rather than a FICS/ICC update to Picochess.

Reply to this email directly or view it on GitHub: https://github.com/jromang/picochess/issues/44#issuecomment-139614106

[djdekker]

Wow... remote playing/sharing/teaching/watching/commenting sounds really cool Shiv!

[ifekali]

I wrote about this on my blog (last part):

http://www.bestchessmenever.com/blog/files/picochess-on-dgt-3000.html

On 11. sep. 2015, at 20.17, DJ Dekker notifications@github.com wrote:

Wow... remote playing/sharing/teaching/watching/commenting sounds really cool Shiv!

• Jonas Žnidaršič jonas@jonas.si

[pablo2000]

Right, that's settled then!

I've got some time coming up in the next week, so I'll start taking a look at the 'remote play'.... Unless someone else has started already?

[sshivaji]

Thats of course ok. You can work on whatever you like, and remote play is great :)

However, I see issues on picochess core in terms of stability. Do you have ideas or can you help with resolving those issues? I am not happy with recent stability issues.

Shiv

On Sat, Sep 12, 2015 at 7:22 AM, Pablo notifications@github.com wrote:

Right, that's settled then!

I've got some time coming up in the next week, so I'll start taking a look at the 'remote play'.... Unless someone else has started already?

— Reply to this email directly or view it on GitHub https://github.com/jromang/picochess/issues/44#issuecomment-139774789.

[djdekker]

Which stability issues do you mean Shiv?

[ifekali]

Picochess cannot finish a game (hangs with debug message "DGT clock locked") on my USB board.

On 12. sep. 2015, at 18.16, DJ Dekker notifications@github.com wrote:

Which stability issues do you mean Shiv?

• Jonas Žnidaršič jonas@jonas.si

[pablo2000]

Happy to help wherever it's needed, but I've got to be honest and say I, personally, don't experience any real problems. I was playing in a tournament a few days ago and used pico to prepare and was playing 5-6 hours at a stretch for several days without any problems (well, except my chess!).

I've a feeling the issues experienced relate to the USB interface - Bluetooth seems pretty solid. That being said I have pico on a ' bare bones' Pi2 that isn't used for anything else at all not even a gui.

[ifekali]

Bluetooth seems solid to me also, but on USB board a game cannot be finished.

On 12. sep. 2015, at 23.09, Pablo notifications@github.com wrote:

Happy to help wherever it's needed, but I've got to be honest and say I, personally, don't experience any real problems. I was playing in a tournament a few days ago and used pico to prepare and was playing 5-6 hours at a stretch for several days without any problems (well, except my chess!).

I've a feeling the issues experienced relate to the USB interface - Bluetooth seems pretty solid. That being said I have pico on a ' bare bones' Pi2 that isn't used for anything else at all not even a gui.

— Reply to this email directly or view it on GitHub.

• Jonas Žnidaršič jonas@jonas.si

[pablo2000]

RasPi has a history of buggy USB problems. An old cure used to be to force all USB devices to run at full speed, as a mixture resulted in dropped packets.

Has this been ruled out?

[sshivaji]

That's an interesting idea! We did not think about this at all.

Jonas, maybe we can try something like http://ludovicrousseau.blogspot.com/2014/04/usb-issues-with-raspberry-pi.html ?

Shiv

On Sat, Sep 12, 2015 at 2:15 PM, Pablo notifications@github.com wrote:

RasPi has a history of buggy USB problems. An old cure used to be to force all USB devices to run at full speed, as a mixture resulted in dropped packets.

Has this been ruled out?

— Reply to this email directly or view it on GitHub https://github.com/jromang/picochess/issues/44#issuecomment-139820398.

[ifekali]

I'll try right now

On 12. sep. 2015, at 23.18, Shivkumar Shivaji notifications@github.com wrote:

That's an interesting idea! We did not think about this at all.

Jonas, maybe we can try something like http://ludovicrousseau.blogspot.com/2014/04/usb-issues-with-raspberry-pi.html

• Jonas Žnidaršič jonas@jonas.si

[ifekali]

I tried it, but this seems to make it worse, freezes on first move ... (But somebody should confirm this separately. Am I the only one with a USB board?)

On 12. sep. 2015, at 23.18, Shivkumar Shivaji notifications@github.com wrote:

That's an interesting idea! We did not think about this at all.

Jonas, maybe we can try something like http://ludovicrousseau.blogspot.com/2014/04/usb-issues-with-raspberry-pi.html ?

• Jonas Žnidaršič jonas@jonas.si

[RayGil]

I can confirm it freezes on 1st move - pi2, USB board.

Ray

Raymond Gilchrist Sent from my iPhone

On 12 Sep 2015, at 23:35, Izmet Fekali notifications@github.com wrote:

I tried it, but this seems to make it worse, freezes on first move ... (But somebody should confirm this separately. Am I the only one with a USB board?)

On 12. sep. 2015, at 23.18, Shivkumar Shivaji notifications@github.com wrote:

That's an interesting idea! We did not think about this at all.

Jonas, maybe we can try something like http://ludovicrousseau.blogspot.com/2014/04/usb-issues-with-raspberry-pi.html ?

• Jonas Žnidaršič jonas@jonas.si

— Reply to this email directly or view it on GitHub.

[pablo2000]

Can anyone confirm whether the Bluetooth board connected on USB misbehaves in the same way. I would imagine it has a different USB-serial chipset?

If it doesn't, it will be a little awkward to help with this, but not impossible. Embedded hardware interface software is kind of 'up my street', so if there's a problem here I can probably add a little value to it.

[pablo2000]

OK... so I can answer that for myself now: No.

I've USB connected my board (appears as ACM0), set the full speed 'fix' that Jonas and Ray tried, rebooted. Picochess came up immeadiately on boot, as it should. Then I played 4 complete games back to back, then a few resign/draws. I tried pico mating me, me mating pico, time out for me, time out for pico, then each of white resigns, black resigns, offer draw. It all works perfectly, no stability issues, all clock functions fine, all PGN outputs fine. I'm currently in the middle of a Fischer 90/30 game and no signs of trouble - except the fish is kicking my ass.... may have to 'test' the resign again in a minute :(

[ifekali]

Fritz on Windows works nicely ...

On 13. sep. 2015, at 00.44, Pablo notifications@github.com wrote:

Jonas/Ray do you have any other software on the Pi that interfaces to the USB board? If so, is that working without any problem?

• Jonas Žnidaršič jonas@jonas.si

[pablo2000]

yes, but anything else on the Pi?

[sshivaji]

Can you make an image out of your setup and upload it? I can share upload credentials with you if you can do this.

I have to admit that I did not look too much into picochess these days but hearing that it's so stable is surprising :)

Shiv

On Sep 13, 2015, at 4:22 AM, Pablo notifications@github.com wrote:

OK... so I can answer that for myself now: No.

I've USB connected my board (appears as ACM0), set the full speed 'fix' that Jonas and Ray tried, rebooted. Picochess came up immeadiately on boot, as it should. Then I played 4 complete games back to back, then a few resign/draws. I tried pico mating me, me mating pico, time out for me, time out for pico, then each of white resigns, black resigns, offer draw. It all works perfectly, no stability issues, all clock functions fine, all PGN outputs fine. I'm currently in the middle of a Fischer 90/30 game and no signs of trouble - except the fish is kicking my ass.... may have to 'test' the resign again in a minute :(

If the stability is as bad as it seems for some USB setups, we really need to get a handle on the system configurations. Lets start with the chipsets. Jonas/Ray what boards are you using (usb, bluetooth over usb, age etc), please can you post (or send me) the output from running 'lsusb', a directory listing for /dev, details of your Pi config, result of 'uname -r'. That should get us started.

— Reply to this email directly or view it on GitHub.

[pablo2000]

I can do that Shiv, without doubt. However, my install is just Jonas 0.43 image, with the /opt/picochess folder deleted and a new clone of the master branch, and then some engines and books added. A few config files changed (for WiFi, fstab for mounting flash drives etc). I have speech disabled - while I do like it, I have found some problems with message queuing (need to look at those), like the web interface lags by many moves with speech on.

I think there may possibly be a point here: I only use my RPi for picochess. Nothing else. If I'm coding directly on the RPi I use nano, no IDE installed. It's about as plain and simple as it could be (which I'm not sure is true of everyone's setup. I have a plain old 'Plugable' brand bluetooth dongle and a new-ish bluetooth board. I'm not exaggerating, it really is solid. I wouldn't be adding engine swaps and controls from clock etc if it still had fundamental problems. I've taken it on the road with me - board/pieces and clock in the nice DGT canvas travel bag, RPi and battery in the spare pocket and I'm computer free.

[sshivaji]

Interesting. I will test later today and report.

Shiv

— Sent from Mailbox

On Sun, Sep 13, 2015 at 10:11 AM, Pablo notifications@github.com wrote:

I can do that Shiv, without doubt. However, my install is just Jonas 0.43 image, with the /opt/picochess folder deleted and a new clone of the master branch, and then some engines and books added. A few config files changed (for WiFi, fstab for mounting flash drives etc). I have speech disabled - while I do like it, I have found some problems with message queuing (need to look at those), like the web interface lags by many moves with speech on.

I think there may possibly be a point here: I only use my RPi for picochess. Nothing else. If I'm coding directly on the RPi I use nano, no IDE installed. It's about as plain and simple as it could be (which I'm not sure is true of everyone's setup. I have a plain old 'Plugable' brand bluetooth dongle and a new-ish bluetooth board. I'm not exaggerating, it really is solid. I wouldn't be adding engine swaps and controls from clock etc if it still had fundamental problems. I've taken it on the road with me - board/pieces and clock in the nice DGT canvas travel bag, RPi and battery in the spare pocket and I'm computer free.

Reply to this email directly or view it on GitHub: https://github.com/jromang/picochess/issues/44#issuecomment-139896229

[ifekali]

On 13. sep. 2015, at 13.22, Pablo notifications@github.com wrote:

If the stability is as bad as it seems for some USB setups,

USB seems to work just fine on the bluetooth board. The bluetooth board works fine over bluetooth and USB. I always get a greeting message ("PICO 053") on the bluetooth board, regardless of connection type.

I'm only getting the freezes ("DGT clock locked") on my two USB boards. Never get the greeting version number message.

we really need to get a handle on the system configurations. Lets start with the chipsets. Jonas/Ray what boards are you using (usb, bluetooth over usb, age etc),

I am using:

1. A bluetooth board bought in 2012.
2. An older (circa 2008) tournament serial board (RS232) that I converted to USB with original DGT serial to USB conversion kit. Basically you get new PCB usb board, you only keep the wiring inside the board. The conversion was done in 2014. This setup should be practically identical to new USB boards.
3. A homemade wooden board with original DGT USB printed circuit board and wiring. (I asked the DGT shop to provide mi with electronics to build my own board. They sold me everything except the wood.) This setup is practically identical to new USB boards, year 2015.

please can you post (or send me) the output from running 'lsusb',

This is my bluetooth board output: pi@raspberrypi /opt/picochess $ lsusb Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. Bus 001 Device 004: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter Bus 001 Device 005: ID 04d8:000a Microchip Technology, Inc. CDC RS-232 Emulation Demo

And this is my USB board output: pi@raspberrypi ~ $ lsusb Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. Bus 001 Device 004: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

a directory listing for /dev, details of your Pi config,

engine = /opt/picochess/engines/stockfish uci-option = Threads = 4 log-level = debug log-file = /opt/picochess/picochess.log

result of 'uname -r'. That should get us started.

bluetooth board uname: pi@raspberrypi /opt/picochess $ uname -r 4.1.6-v7+

• Jonas Žnidaršič jonas@jonas.si

[pablo2000]

Thanks Jonas, that's really helpful.

So we've learned that the boards based on the PIC micro-controller software emulated UART work fine and the 'problem' boards are based on the FTDI converter chip. The plot thickens!

Now, with the USB board connected exactly as before (ie same USB socket), please do: "sudo lsusb -D /dev/bus/usb/001/005" and send the results, and then "sudo usb-devices" and send the results.

I'm sorry, but each output is quite long, but this will be very useful. I'm pretty sure I have a converter cable using the same FTDI chip round here somewhere, that might prove useful for testing.

[pablo2000]

Also I notice your linux version is not the same as the one on your image file. I need to find out what driver changes (if any) were made between those versions.

[ifekali]

On 13. sep. 2015, at 23.57, Pablo notifications@github.com wrote:

Now, with the USB board connected exactly as before (ie same USB socket), please do: "sudo lsusb -D /dev/bus/usb/001/005" and send the results, and then

pi@raspberrypi ~ $ sudo lsusb -D /dev/bus/usb/001/005 Device: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 4.00 iManufacturer 1 FTDI iProduct 2 USB <-> Serial iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 90mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 USB <-> Serial Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered)

"sudo usb-devices" and send the results.

pi@raspberrypi ~ $ sudo usb-devices

T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=04.01 S: Manufacturer=Linux 4.1.6-v7+ dwc_otg_hcd S: Product=DWC OTG Controller S: SerialNumber=3f980000.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub

T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 5 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1 P: Vendor=0424 ProdID=9514 Rev=02.00 C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=2mA I: If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub

T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0424 ProdID=ec00 Rev=02.00 C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=2mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff Driver=smsc95xx

T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=148f ProdID=5370 Rev=01.01 S: Manufacturer=Ralink S: Product=802.11 n WLAN S: SerialNumber=1.0 C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=450mA I: If#= 0 Alt= 0 #EPs= 7 Cls=ff(vend.) Sub=ff Prot=ff Driver=rt2800usb

T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0403 ProdID=6001 Rev=04.00 S: Manufacturer=FTDI S: Product=USB <-> Serial C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=90mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio

• Jonas Žnidaršič jonas@jonas.si

[pablo2000]

Great.

Now, when picochess starts, either from the command line or as a service, does it show the device config, for the serial boards, as "/dev/ttyusb0", or "/dev/ttyacm0" ?

[pablo2000]

Last one... Can you boot the RPi with the serial board attached, and then send me the output from: "sudo dmesg | grep FT232" so I can get the chip version.

I have a pretty solid idea about the problem and it's cause now, as these issues are rather well known.

[ifekali]

After replacing the printed circuit board, my board is USB, not serial. it shows up as /dev/ttyusb0.

On 14. sep. 2015, at 00.06, Pablo notifications@github.com wrote:

Now, when picochess starts, either from the command line or as a service, does it show the device config, for the serial boards, as "/dev/ttyusb0", or "/dev/ttyacm0" ?

• Jonas Žnidaršič jonas@jonas.si

[ifekali]

pi@raspberrypi ~ $ sudo dmesg | grep FT232 [ 12.821961] usb 1-1.3: Detected FT232BM

On 14. sep. 2015, at 00.21, Pablo notifications@github.com wrote:

Last one... Can you boot the RPi with the serial board attached, and then send me the output from: "sudo dmesg	grep FT232" so I can get the chip version.

Jonas Žnidaršič jonas@jonas.si

[pablo2000]

Sorry with the slow response.

Thanks Jonas for the information. Yes I understood that the boards were now USB not serial - I just chose my words poorly.

Well, good news. I'm virtually certain I understand the problem, which relates to the combination of driver version and chip version. Unfortunately, the FTDI virtual com port drivers on (especially) the RPi are a bit hit and miss. So, I'm working up a version of dgtserial.py that will bypass the kernel driver and work directly with the FTDI chip, and some supporting libraries. It will take a few days - partly as I couldn't find a converter with the same device in it so I've had to order one which will take a couple of days to arrive - but rest assured I'm on with it and will come up with a solution!

[pablo2000]

Update: my test hardware arrived this evening - will be back on this in parallel with remote play.

[pablo2000]

Update: I constructed a pseudo usb board based on the FTDI chipset used in the DGT boards, and managed to replicate the problem (or at least a problem) using the default kernel driver. I have now written a replacement for the driver, based around the libftdi library and so far it seems good - no hangs and it's been running for about 18 hours. I'm not going to check it in until Niklas changes to libraries have been merged and my remote code is in place. But it looks like progress - should be available in a few days.

[sshivaji]

Fantastic work!!

I will go ahead and merge in Niklas’s change ASAP.

Shiv

— Sent from Mailbox

On Wed, Sep 23, 2015 at 12:35 PM, Pablo notifications@github.com wrote:

Update: I constructed a pseudo usb board based on the FTDI chipset used in the DGT boards, and managed to replicate the problem (or at least a problem) using the default kernel driver. I have now written a replacement for the driver, based around the libftdi library and so far it seems good - no hangs and it's been running for about 18 hours. I'm not going to check it in until Niklas changes to libraries have been merged and my remote code is in place. But it looks like progress - should be available in a few days.

Reply to this email directly or view it on GitHub: https://github.com/jromang/picochess/issues/44#issuecomment-142706353

[sshivaji]

Pablo, what is the status on this, can we merge this in to master for more testing?

Thanks, Shiv

[pablo2000]

Hi Shiv / all

sorry for having 'vanished' for the last couple of weeks - I've had a family situation that required me to be away from home to help my dad. Coming to a finish now - normality is returning!

So, today I am pushing up the remote play work so far (still a few things to do - details on that thread) and then I can look to get this new driver merged and pushed up.

[sshivaji]

No problem at all!

Looking forward to your commits. Eventually I want to append my changes after your commit.

Shiv

On Oct 14, 2015, at 3:33 AM, Pablo notifications@github.com wrote:

Hi Shiv / all

sorry for having 'vanished' for the last couple of weeks - I've had a family situation that required me to be away from home to help my dad. Coming to a finish now - normality is returning!

So, today I am pushing up the remote play work so far (still a few things to do - details on that thread) and then I can look to get this new driver merged and pushed up.

— Reply to this email directly or view it on GitHub.

[LocutusOfPenguin]

@pablo2000 Is the driver ready for merge?

Jürgen