jernej replied at 2016-2-15 03:31
It's only in comments and even there is represented as an example of alternative wiring. Do you ha ...
I plugged the display and do not work. Blinking a backlight and no display. Had to seek at the cause and add to the configuration file configuration of the the connection.
Converters i2c to the display mainly occur in one of the default configuration. So the same configuration should be set in the system.
Not that plug in and I have to look further why does not work!
lymon replied at 2016-2-14 07:54
I know, but as it says in the "latest prebuilt images" topic that the images are with PVR addons in ...
I updated the patch. Can you please pull latest changes and test again? As I said in my previous post, if kodi doesn't reboot (e.g. crashes and creates a crash log), enable debug log and reproduce the issue. Then please send me both log files (kodi.log and kodi.old.log).
@GUTEK@ replied at 2016-2-15 02:43
jernej
There is a bug in the patch to lcdproc:
Address BL is 0x80 (i2c_line_BL=0x80) should be 0x08 ...
Whatever he is telling about is a typo in the example mentioned in the README in the original patch github page
I tested the LCDproc along with the XBMClcd Addon and it works beautifully using a 16x2 lcd along with an pcf8574T i2c backpack. With longer lines the scroll speed is too fast with the default addon settings. You can change that in the XBMCLCDproc addon configure options along with backlight behaviour and few others.
I also noticed that with the mainline IR driver irrecord consistently failed to detect the gap with couple of remotes that I tried. Reverting to the legacy driver resolved the issue. So I think it is better to revert to the legacy driver till the mainline driver improves unless there is a different test report which proves the case otherwise.
I'm totally in for the H3 rewrite and we should plan and start whenever the time is right.
jeevasv replied at 2016-2-15 00:38
Whatever he is telling about is a typo in the example mentioned in the README in the original patch ...
There is not necessarily a bug in IR driver, could be also bug in input/rc subsystem. I would rather fix this than go back. Unfortunately, there is so many requests that is hard to keep up. Pull requests would be very welcome.
jernej replied at 2016-2-15 14:46
There is not necessarily a bug in IR driver, could be also bug in input/rc subsystem. I would rath ...
Probably you are right but ir-keytable -t --sysdev=devinput -d /dev/input/event1 is working properly and is detecting a keydown and keyup events as it should.
Only the irrecord fails and detect gap and quits. It seems to detect something when keys are manually repetitively pressed rather than kept depressed. So by vague guess looks more on the IR driver side rather than the input side. Would like to see the behaviour with mainline kernel to confirm.
Anytime is right time for a proper rewrite. I'm not following the mainline kodi development timelines. Since you mentioned a major kodi overall is in the pipeline which better reorganizes the way new devices are supported I thought we may want to wait/follow that inorder to avoid rework later
I think enabling one -wire and spi0 in all three fex files should be enough for the time being.
I also think people are having better opinion about running OPiPC image in the OPiOne board by just replacing script.bin. Whenever you have some time Just clone the current OPiPC folder as OPi-One. And later I can provide the files to be replaced or give you a pull request.
-Cheers
[Copy link]
Show IP Card
Radar Card
Published in 2016-2-15 03:53:23
Anonimous Post
Published in 2016-2-15 05:39:25
