search

xbmc-imx6 / libcec

USB CEC Adapter communication Library http://libcec.pulse-eight.com/
Other
8 stars 3 forks source link

3.10.30 kernel #1

Closed emveepee closed 10 years ago

emveepee commented 10 years ago

Stéphan, is this version of libcec compatible with the 3.10 kernel? It is part of the current GeexBox distro but users have been reporting that cec is not working. Here is come cec-client output if that provides any insight http://imx.solid-run.com/forums/viewtopic.php?f=7&t=641&p=6485

wolfgar commented 10 years ago

Sorry, it is on my todo list, I have not yet checked for 3.10 nor addressed fully the previous issue regarding off/on or unplug/plug cycle No only is free time difficult to find but also investigating cec is not so easy for me because only my main TV is CEC able and I have to share it with my family ;)

tomlohave commented 10 years ago

the kernel patch you mentionned on your blog is not yet integrated on kernel 3.10.30

emveepee commented 10 years ago

Merci à vous deux. I thought that it was something out of your control but I wanted to be certain.

andrasbiro commented 10 years ago

I ported the patch to 3.10.30: https://dl.dropboxusercontent.com/u/363226/hdmi-cec.patch The diff is made against the top of the cubox-i kernel at solidrun's github. It should work everywhere, but here's the modified file if not: https://dl.dropboxusercontent.com/u/363226/mxc_hdmi-cec.c

Basicly I just gone through the original patch, and made the modifications on the right positions, it didn't changed much. I didn't gone through the protocol and/or the sourcecode. The only problem I found was that hdmi_cec_data.cec_irq was removed, so the free-ing seemd unnecessary.

It seems like it's working with cec-client, I see the buttons I press on the remote, I managed to turn the TV on/off, XBMC doesn't complains that it can't connect, but it's still doesn't work in xbmc.

Oh, I'm testing the whole thing on arch on a cubox-i4, with panasonic TV (TX-L47ET60E)

wolfgar commented 10 years ago

Thank you for porting my patch to 3.10 For irq free-ing, I fear you still have to free it but now you have to call devm_free_irq ... I wonder why it does not work with xbmc : have you turned on debug log ? do you have a correct keymap file ?

andrasbiro commented 10 years ago

Yes, XBMC doesn't seems to receive any keypress based on the debug. I'm suspecting the keymap too, but I don't know where should it be

wolfgar commented 10 years ago

hmm if xbmc cannot see the CEC remote messages then it likely not related to the keymap... with debug enabled, you should have entries like : DEBUG: OnKey: xxxxx (xx) pressed, action is xxxxxxx when CEC works ...

andrasbiro commented 10 years ago

I see this for every keypress in cec-client (without any argument), is this what it should be? TRAFFIC: [ 30861] >> 04:44:04 DEBUG: [ 30861] >> TV (0) -> Playback 1 (4): user control pressed (44) DEBUG: [ 30861] key pressed: right (4) TRAFFIC: [ 30991] >> 04:45 DEBUG: [ 30991] >> TV (0) -> Playback 1 (4): user control release (45) DEBUG: [ 30991] key released: right (4) And this is the cec related part of xbmc.log: http://pastebin.com/mQAz21JH

wolfgar commented 10 years ago

Yes cec-client works fine and you receive correctly the remote key events xbmc initialization seems good at first sight : Sorry further investigations are needed, I don't know what the issue is

mk01 commented 10 years ago

from docs

The devm_request_irq function allocates irq that is released
when a driver detaches. Thus, there is no reason to explicitly
call devm_free_irq in probe or remove functions.
wolfgar commented 10 years ago

ho sorry, thanks for pointing it, you are perfectly right I was not so familiar with this new function and fooled by the remaining explicit calls.. Speaking about this driver I have just updated it : here and here...

andrasbiro commented 10 years ago

Okay, turns out my bug is a funny one. Checking the log files more than a minute revealed that CEC actually stops responding after a few writes, and xbmc sets itself as recording device. The intresting thing is, the last reply was never the same, but always before xbmc changed the refresh rate of the screen. So I modified /sys/class/graphics/fb0/mode to read-only, which disables the whole refresh rate changing class, and cec started working. I guess changing the refresh rate broke the hdmi connection for a split second, and the cec driver collapsed. I'm not sure if my patch above works the same, I did some modification, including the patches in your previos posts, but I will post a working patch here in the weekend.

wolfgar commented 10 years ago

ok ! very interesting finding and It makes sense... Can't you only disable the refresh rate in settings->video->playback : "adjust display refresh rate" instead of changing mode file to read only ?

andrasbiro commented 10 years ago

I could, but on startup, xbmc always do something (the screen flickers), even though it should remain at 60Hz. That's the point when the cec collapses. In the debug log: 12:26:40 T:1959591936 NOTICE: Initialize - graphics sysfs is writable 12:26:40 T:1959591936 NOTICE: InitWindowSystem: Using EGL Implementation: iMX 12:26:40 T:1959591936 NOTICE: Found resolution 720 x 480 for display 0 with 720 x 480 @ 60.000000 Hz [removed some resolutions from here] 12:26:40 T:1959591936 NOTICE: Found resolution 1920 x 1080 for display 0 with 1920 x 1080 @ 60.000000 Hz 12:26:40 T:1959591936 NOTICE: Found (1920x1080@60.000000) at 23, setting to RES_DESKTOP at 16 12:26:40 T:1959591936 NOTICE: Checking resolution 16 12:26:41 T:1959591936 DEBUG: SetNativeResolution: S:1920x1080p-60

wolfgar commented 10 years ago

So even with the option disabled, cec does not work with xbmc and you have to use the permission trick ? we may write to this file even if we are already at the expected rate, I will check ... As a side note, I also have a panasonic tv (but different model) and I am not hit by this funny issue

Have you understood what the exact underlying issue is : is a message definitively lost ? is the TV itself buggy regarding its cec behavior when the input signal changes ? something else?

andrasbiro commented 10 years ago

Exactly, I think it re-sets the refresh rate to 60. Strange. I had problems with the refresh rate change anyway: sometimes it just shows me the arch login screen (sound and control works), I think because it sets to a wrong rate. Do you plug your device directly to the TV (like me), or do you have an audio receiver?

Not quite. That's what I know so far: After the last write command (usually input change or vendor name request) before refresh rate change, the expected response never come. After that, every write says "sent command error" (probably timeout: the error come 1s after the write itself). The kernel module debug never sends interrupt after this point. I only see write/poll (while xbmc searches for devices), and finally poll only. Changing the input, turning off the tv, nothing helps. hdmi_cec_dev_probe didn't printed that "HDMI CEC initialized" But I will probably play with this on the weekend, I wanted to better understand the kernel anyway.

wolfgar commented 10 years ago

in my own setup, I am directly connected to the TV...

hmm ok, whether you are no longer able to send for some reason whether the TV no longer ack your messages... And it happens every time you relaunch xbmc with 100% rate ? If you launch cec-client after xbmc, is the behavior still broken ? If so, if you unload/reload the driver, does it make a difference ?

andrasbiro commented 10 years ago

I might have successfully started xbmc one or two times with resolution change and cec enabled, but I'm not sure. I would say, it's 99% rate, maybe 100%. No nead to reload the module, even restarting xbmc with read-only sysfs works. Based on your questions, the easiest way to reproduce the bug:

  1. start cec-client, check if everything works
  2. "tx f0:8c" will response 0f:87:00:80:45. Even if I turn off the tv, switch input, etc.
  3. change the refresh rate from a different console with fbset
  4. "tx f0:8c" will fails with "write sent error" (probably timeout). Even if I turn off the tv, switch input, etc.
  5. restart cec-client and everything works again.
koying commented 10 years ago

@andrasbiro Normally, the resolution is not changed at XBMC startup if the resolution configured in XBMC is the same as the current one.

Assuming you specified 1920x1080x60 in XBMC, in which resolution is the board started?

andrasbiro commented 10 years ago

cat /sys/class/graphics/fb0/mode S:1920x1080p-60 systemctl start xbmc cat /sys/class/graphics/fb0/mode S:1920x1080p-60

But it not just the resolution change. I can only start xbmc with cec this way:

  1. console prompt
  2. xmbc start (screen flickers)
  3. xbmc restart (screen doesn't flickr) If the sysfs is writable, it flicers in the third step, and cec doesn't work.
wolfgar commented 10 years ago

@andrasbiro : thanks for your additional data, I will try to reproduce this evening... your item 4 "4. restart cec-client and everything works again." is encouraging as it means there is a way to solve it by sw for sure...

andrasbiro commented 10 years ago

@wolfgar OK, probably I will be around my device too, if you need testing. I'm using the 3.10 kernel (on arch, downgrading is usually hard and ugly), but this module is very similar.

andrasbiro commented 10 years ago

Actually, it might be the kernel difference: The main difference is that it uses module_platform_driver() instead of module_init() and module_exit(). Everything from these functions moved to the probe() and remove(). It made sense for me, why need the device when it's not connected.

But if libcec keeps the device open, and my TV reconnects when it flickers, it creates a new device (I'm not sure where it's exists in the filesystem, since its name is occupied), and libcec works with the destroyed device. Am I on the right path?

Here's an easily diffable (with your newest utilite version) version of the 3.10 module: https://dl.dropboxusercontent.com/u/363226/cec/3/mxc_hdmi-cec.c

wolfgar commented 10 years ago

I have reproduced the issue : In fact when you change HDMI rate, CEC clock is disabled so you don't send anything... Please check the commit I have just pushed

wolfgar commented 10 years ago

In fact the underlying issue is that the handling of event FB_EVENT_MODE_CHANGE (in mxc_hdmi.c) calls mxc_hdmi_setup which calls mxc_hdmi_enable_video_path which disables all HDMI clocks and re-enables them one after the other but nobody cares about the required cec clock state so it remains disabled... NB : all references are related to 3.0.35 kernel but I guess it should be similar in 3.10x

andrasbiro commented 10 years ago

Yep, that was the problem, thank you very much!

wolfgar commented 10 years ago

I thank very much : you have done the hardest part of the work by finding a simple way to reproduce this issue... So now you have a fully working CEC in XBMC with kernel 3.10x ?

andrasbiro commented 10 years ago

Well, it works for sure, even with 24hz playback. I don't know if it cleans up after itself on unload and so on - I'm not a kernel developer. I had other an other issue with it when the tv is turned off for a few hours, it's really hard to reconnect the cec. I had to disable cec in xbmc, reenable it, change input source on the tv, I don't really know, some of them fixed it. But it's probably related: I think I had to change input source even when started xbmc with the workarounds above - with this patch it works immediately.

rkorn86 commented 10 years ago

Hey you two. Big thx for all your work. Andras, as i read, you are using arch with 3.10 Kernel, could you please share your patched kernel and libcec package?

thx so much!

Am 25.04.2014 22:56 schrieb =?ISO-8859-1?Q?Andr=E1s_B=EDr=F3?= notifications@github.com:

Yep, that was the problem, thank you very much!

Reply to this email d Yep, that was the problem, thank you very much!

Reply to this email directly or view it on GitHub: https://github.com/xbmc-imx6/libcec/issues/1#issuecomment-41438537

wolfgar commented 10 years ago

@andrasbiro : That's great ! yes please share the final CEC driver file for 3.10 so that mainteners of distro who package 3.10 kernel can have working CEC @rkorn86 I hope it also solves the issue you reported a few weeks ago, please keep us informed...

andrasbiro commented 10 years ago

Of course, I want to send a pull request to solidrun. Working on it.

mk01 commented 10 years ago

guys,

there are patches I sent to jnettlet a while ago, but they are not integrated to 3.10 yet. https://github.com/mk01/linux-linaro-stable-mx6/commit/c3a8313a97dc40a18f809ad1154c606c6b29d65f https://github.com/mk01/libcec/commits/master

wolfgar commented 10 years ago

@mk01 you should have pushed a notification to me at the time you wrote this patch ! You had obviously already identified the issue I have just discovered tonight in mxc_hdmi.c regarding CEC clock reenabling... By the way, it is better to solve the issue in mxc_hdmi as you have done. Yet I am unsure about your change in mxc_edid.c : Are you sure nobody else use the physical_address format and you can change it ? Regarding this topic, I have also found the issue this week and fixed it in libcec : https://github.com/xbmc-imx6/libcec/commit/d821a5f9b03a436950570ee9d7741452248f72e8

Please in the future do not hesitate to drop me a little note when you improve items related to xbmc on imx6...

andrasbiro commented 10 years ago

@mk01 You could save a few hours for us... @wolfgar Unfortunately, the long turned off tv - reconnection bug is still present. I need to turn off the cec peripherial, then on again, switch the tv's input to something else, than back to the cubox. I will try with @mk01's version.

I guess I shouldn't bother with my patch then. Well anyway, here's the ugly version of mxc_hdmi-cec.c, if anyone's intrested (nothing else was changed): https://dl.dropboxusercontent.com/u/363226/mxc_hdmi-cec.c

wolfgar commented 10 years ago

@andrasbiro : Thanks a lot for your final file... I have quickly reviewed the changes proposed by mk01 for libcec : there is at least an interesting implementation of HandleLogicalAddressLost method that may help in some cases...

wolfgar commented 10 years ago

I have merged hdmi patch for HDMI https://github.com/wolfgar/utilite/commit/5403341d8e35384a4efb4c5a6a00d023c6b668b6 and added improvements in libcec https://github.com/xbmc-imx6/libcec/commit/42c3c07a79b8155635851c2eed9558b221b89047 from mk01... Thanks

andrasbiro commented 10 years ago

@wolfgar Is your libcec version (which is the default on cuboxi arch) compatible with mk01's kernel?

wolfgar commented 10 years ago

No : it is no longer compatible with my patch which gets rid of ACK/NACK events (https://github.com/wolfgar/utilite/commit/342b93f740d53291fcef3f56df4ee00e96b302cb) Edit : Sorry I have misunderstood your question I think : my libcec is very likely compatible with his kernel but the opposite is not true as I said...

wolfgar commented 10 years ago

A last update : TV off / on works fine after this merge : https://github.com/wolfgar/utilite/commit/5403341d8e35384a4efb4c5a6a00d023c6b668b6 grabbed from mk01 Issue was still this cec clock of course (the bug was still the same -> buggy hdmi driver disables cec clock and so we do not receive further notifications from tv )

rkorn86 commented 10 years ago

mh.... using archlinux with 3.10.17-8-ARCH Kernel (and manually patched https://github.com/wolfgar/utilite/commit/5403341d8e35384a4efb4c5a6a00d023c6b668b6) I dont get cec-client to run.

# cec-client 
No device type given. Using 'recording device'
CEC Parser created - libCEC version 2.1.4
no serial port given. trying autodetect: FAILED
# ls -al /dev/mxc_*
crw-rw-rw- 1 root root   10, 60  1. Jan 1970  /dev/mxc_asrc
crw-rw-rw- 1 root video 248,  0  1. Jan 1970  /dev/mxc_hdmi
crw-rw-rw- 1 root root  250,  0  1. Jan 1970  /dev/mxc_ipu
crw-rw---- 1 root video 246,  0  1. Jan 1970  /dev/mxc_vpu

normally there should be sth like /dev/mxc_hdmi_cec

Is it an archlinux issue or is cec just not yet ready on wandboard with kernel 3.10.17?

wolfgar commented 10 years ago

you driver is obviously not loaded... Please try to use the driver posted by andras : https://dl.dropboxusercontent.com/u/363226/mxc_hdmi-cec.c

rkorn86 commented 10 years ago

ive used this driver..... trying to build it as a kernel module to see if something fails while loading....

andrasbiro commented 10 years ago

FYI, my module was based on solidrun's 3.10 kernel, which is the kernel source of arch's linux-imx6-cubox-dt. But I'm using mk01's kernel and libcec, even the long turned off bug is fixed (probably fixed in wolfgar's last patch as well)

@wolfgar @mk01 You should at least agree on the libcec-kernel interface. Pulse-eight would probably accept the imx6 driver into the mainline, but nobody would accept if the two widely accepted kernel version communicates differently. I hate using sources that didn't come from the official source, they usually became unmaintained. I see that it's almost impossible to use the mainline kernel on an ARM device. But libcec and xbmc should be merged eventually into their mainlines.

wolfgar commented 10 years ago

@rkorn86 hmm have you cheched that you have appropriate entry in your dts ? @andrasbiro : yes the tv off bug was once again due to cec clock which was disabled. As I said applying the https://github.com/wolfgar/utilite/commit/5403341d8e35384a4efb4c5a6a00d023c6b668b6 patch will solve it

rkorn86 commented 10 years ago

@wolfgar how should they look like? ive never done something kernel related stuff :(

wolfgar commented 10 years ago

@andrasbiro : About source, I share your concern but I cannot deal with things I am not aware of. So far I have largely written on my blog and explicitly grab libcec for imx6 here exactly to publicly cooperate... I also begin to merge mk01 stuff and commented his patch to initiate collaboration. What more could I do ?

rkorn86 commented 10 years ago

thats what i have in my dts/dtb:

root@wandboard - 14:36:08 - /var/abs/local/linux-imx6-wandboard-dt/src/linux-9d567e4f285e80bc332e79f0636259bc05a4ee3b/arch/arm/boot/dts # fgrep -ri cec imx6q*
imx6qdl.dtsi:   hdmi_cec {
imx6qdl.dtsi:           pinctrl_hdmi_cec_1: hdmicecgrp-1 {
imx6qdl.dtsi:                           MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE 0x1f8b0
imx6qdl.dtsi:           pinctrl_hdmi_cec_2: hdmicecgrp-2 {
imx6qdl.dtsi:                           MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
imx6qdl-sabreauto.dtsi:&hdmi_cec {
imx6qdl-sabreauto.dtsi: pinctrl-0 = <&pinctrl_hdmi_cec_1>;
imx6qdl-sabresd.dtsi:&hdmi_cec {
imx6qdl-sabresd.dtsi:   pinctrl-0 = <&pinctrl_hdmi_cec_2>;
imx6q.dtsi:             hdmi_cec: hdmi_cec@00120000 {
imx6q.dtsi:                     compatible = "fsl,imx6q-hdmi-cec";
imx6q-pinfunc.h:#define MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE        0x088 0x39c 0x88c 0x6 0x0
imx6q-pinfunc.h:#define MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE       0x20c 0x5dc 0x88c 0x6 0x1
Übereinstimmungen in Binärdatei imx6q-wandboard.dtb
wolfgar commented 10 years ago

you have posted the generic imx6qdl part, in fact you have to enable the cec support in wandboard dtsi file by :

&hdmi_cec {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_hdmi_cec_2>;
        status = "okay";
};
andrasbiro commented 10 years ago

@wolfgar You did everything you could, you obviously can't do anything until @mk01 starts communicating.

The problem is the kernel, every board uses a different source tree. You don't use 3.10, so you couldn't merge mk01's patches, or fix the problematic parts. Wouldn't it be possible to create a generic imx6 kernel, where only the dts files are platform dependent?

wolfgar commented 10 years ago

In fact I use 3.10 on some boards (like cuboxi) and 3.0.35 on others because all boards have not yet provided appropriate dts to run 3.10 kernel As far as I understand, the future should clearly look like what you describe : a generic kernel with different dts depending on the boards. This is for the technical part. Unfortunately, I fear there are other questions regarding general maintenance of imx6 kernel and effort to upstream...