Posts by mglae

thread-3863.html

Please read the Deprecated Stuff section and the answers.

Quote from NinjaMonkeyUK

When I said I'm not too sure about what any of that means, I was referring to your previous post that I had quoted.

This disables the start of lircd via udev. You have asked about it.

Quote

I am aware that the code I posted disables the eventlircd service, but it does not do it on subsequent boots unfortunately

Really? As long the link exists eventlircd is not started by systemd. Did you check with

ps|grep eventlircd

Quote from NinjaMonkeyUK

I'm not too sure what any of that means but I did find the following code from the OpenELEC forums:

Code

ln -sf /dev/null /storage/.config/system.d/eventlircd.service
sync && reboot

This disables systemd's eventlircd service on following boots by overriding the normal /usr/lib/systemd/system/eventlircd.service file.

Quote

This fixes my issue after the reboot! All keys on the IR keyboard (remote) start working again. However, once I reboot for a second time, it stops working again. It looks to me like the above code creates a symbolic link from /dev/null to the LIRCD service which basically stops LIRCD from working completely. This is fine as it allows IR-KEYTABLE to work but I cannot figure out how this code should be implemented to work on every boot!

At least I'm getting somewhere now and I know this is possible in LibreELEC.

There is a nice picture in the yaVDR documentation describing the eventlircd input device handling on 3.3. Remote Control. There are differences in details to LibreELEC but it may help to get an idea how your IR receiver is working in the system.

Quote from CGarces

So I'm using DRI3 + GLAMOR? not DRI2 and exa as specified in the xorg-radeon.conf comment?
Is the correct/better configuration for my GPU?

Only Glamor is implemented for Kabini, the configuration is correct.

Quote from CGarces

Also receive incorrect temperatures in the system information.

CPU and GPU show 1ºC

AMD virtual temperatures, see k10temp\hwmon\Documentation - kernel/git/stable/linux-stable.git - Linux kernel stable tree

Quote from NinjaMonkeyUK

There must be a way to permanently disable LIRC / LIRCD so that only IR-KEYTABLE processes IR commands in-kernel.

Do not know if it helps but you can disable the udev lirc rules with

: >/storage/.config/udev.rules.d/98-lircd.rules

and/or mask the lirc systemd units with

: > /storage/.config/system.d/[email protected]
: > /storage/.config/system.d/[email protected]

and reboot

Quote from NinjaMonkeyUK

EDIT: Here is an excerpt from my kodi.log. It looks like I was right; LIRC is intercepting IR signals and dropping those it doesn't understand!

11:49:02.518 T:140430158071040 DEBUG: LIRC: Update - NEW at 71677:2e 0 KEY_C devinput (KEY_C)
11:49:02.767 T:140430158071040 DEBUG: LIRC: Update - NEW at 71926:2e 0 KEY_C_UP devinput (KEY_C_UP)

You can map unknown lirc keys to kodi remote keys using Lircmap.xml.

cp /usr/share/kodi/system/Lircmap.xml /storage/.kodi/userdata/

Edit the devinput section (in your case), i.e.:

...
<remote device="devinput">
<menu>KEY_C</menu>
...

See LIRC - Official Kodi Wiki

Quote from streilu

Could you probably please share a generic build with official dd drivers?

It was one build with experimental features/changes and is already deleted because youtube did not work any more.

Quote from CvH

yes known problem, official drivers do not compile at kernel 4.9 - so nothing i can do till they fix their drivers (the oss drivers that i use have no support for v7)

Which error do you see? I tested the official drivers successfully about two weeks ago using this package.mk.

It may look familiar to you as it is "borrowed" from your GitHub repository.

Maybe checking udev's knowledge about the partitions gives an idea:

udevadm info /dev/sda1
udevadm info /dev/sda2

Quote from CvH

no the 4.8 patch had a lot merge conflicts also without the tbs patch (at least milhouse told so)

Yes, it looks like the DVB API is changing on every mayor kernel release. The patch must match the kernel version. I can nearly promise the 4.9 patch will not work on 4.10 - but the 4.10 patch is already WIP.

Quote from Deepjungle

But why does it work with less than 8.388.240 MB without any problems. I dont know the exact value when it is overturning but it must be between 8.388.240 MB (working) 8.399.999 MB (not working).

The device size is detected different (and you swapped the two log files

1022 dmesg log:

[ 9.840137] sd 0:0:0:0: [sda] 17581277184 512-byte logical blocks: (9.00 TB/8.19 TiB)

1031 dmesg log:

[ 9.733719] sd 0:0:0:0: [sda] 23441768448 512-byte logical blocks: (12.0 TB/10.9 TiB)

But I have currently no idea what is causing this.

Quote from CvH

Ah yea, 4.8 uses a dd bridge patch from 3rd party, that won't work at 4.9 and was dropped. Looks like 4.9 don't support your card completely

The ddbridge patch for 4.9 is working fine on my DD Cine CT V6 with my private build. Unfortunately it was conflicting with the TBS driver patches that has been added to the LibreELEC 4.9 kernel and could not be updated.

As the TBS driver patches are removed in the meantime I will PR the ddbridge patch again the next few days.

Quote from jau

That does work, but it causes other problems. With the ethernet device no longer managed by connmand, the DNS configuration can't be changed because it's hard coded into the systemd unit file for the connman service. DNS1 and DNS2 get set to Google's DNS servers.

cp /usr/lib/systemd/system/connman.service /storage/.config/system.d/

And edit the file in /storage/.config/system.d to your needs.

Quote

Next I tried the following autostart.sh file:

Code

# Kill lirc remote services


systemctl stop eventlircd.service


#start ir-keytable


ir-keytable -c -p RC-5,RC-6 -w/storage/.config/rc_keymaps/myremote

eventlircd must not be stopped in autostart.sh when changing key tables.

The remote can be tested with evtest from the system-tools addon:

systemctl stop kodi
systemctl stop eventlircd
evtest

Select the remote's /dev/input/eventX and start pressing keys.

Quote

22:38:36.806 T:546425532640 INFO: ffmpeg[7F397FF0E0]: Stream #0:0: Video: h264 (High 10), yuv420p10le, 1920x800 [SAR 1:1 DAR 12:5], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)

22:38:36.808 T:546425532640 NOTICE: Opening stream: 0 source: 256
22:38:36.808 T:546425532640 NOTICE: Creating video codec with codec id: 28
22:38:36.808 T:546425532640 DEBUG: FactoryCodec - Video: amcodec - Opening
22:38:36.808 T:546425532640 DEBUG: FactoryCodec - Video: amcodec - Failed
22:38:36.808 T:546425532640 DEBUG: FactoryCodec - Video: - Opening
22:38:36.808 T:546425532640 NOTICE: CDVDVideoCodecFFmpeg::Open() Using codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
22:38:36.808 T:546425532640 DEBUG: CDVDVideoCodecFFmpeg - open frame threaded with 6 threads
22:38:36.809 T:546425532640 DEBUG: CDVDVideoCodecFFmpeg - Updated codec: ff-h264
22:38:36.809 T:546425532640 DEBUG: FactoryCodec - Video: ff-h264 - Opened

Display More

No HW support for H.264 High 10 video and CPU too slow.

The WMV3 issue looks like a driver problem. When it is fixed upstream it will be part the next releases.

A search on freedesktop.org shows two bug reports this year: 96600 – [RV630]: a lot of artifacts appears on a screen playing some videos through VDPAU with hardware acceleration and 94381 – VC-1 VDPAU decoding on radeon causes occasional garbage.

However the three samples from the bug reports play well HW accelerated on my AMD C-60 netbook with 7.90.009.

What is your Kodi settings level?

Being "Expert" there is an additional "Video calibration..." below "Calibration". Furthermore you can disable VC-1 VDPAU acceleration only in player settings.

Quote from schumi2004

Why do i want to do that?
It works now so why change it?

... after the next release. This disables the new default Radeon xorg.conf too and avoids building LE yourself.