<lurchi__>
ther may be bit errors becoming visible as noise
<gnarface>
i also had a issue with a hdmi 1.0 cable causing a device to fail over to raw pcm stereo audio, preventing it from recognizing surround-sound capability of the stereo
<gnarface>
so you can get hdmi version based degredation of audio too
<gnarface>
(something about the raw format only supporting stereo)
<karlp>
lurchi__: but does that trigger a reneg via ddc?
<gnarface>
anyway you don't have to get the most expensive ones on the shelf but i've confirmed through repeated tests that the cheapest ones are never really worth it
<karlp>
I mean, what's the mechanism that a source will negotiate a lower quality datastream based on the connection to the sink?
<gnarface>
i really thought it was a sort of digital handshake, karlp, but lurchi__ seems to know more about it than me
<lurchi__>
karlp: no.
<karlp>
so.... is gnarface seeing .. [insert right name] bias or what then?
<lurchi__>
HDMI for large part functions the same as DVI, which functions like VGA with digital image signals
<gnarface>
when i started running into the types of bugs that care which end of the cable i hotplug, i knew HDMI had gone too far
<lurchi__>
gnarface: makes sense only for "active" cables
<megi>
vagrantc: usb3 is not in mainline
<gnarface>
lurchi__: what you're saying seems to be directly opposite of what numerous people have told me, though they weren't all experts...
<gnarface>
lurchi__: oh. would that caveat also apply to passing passive cables them through an active switch?
<lurchi__>
gnarface: many videophiles are like audiophiles, spending too much money on "oxygen free" cables and similar stuff
Wizzup has quit [Ping timeout: 240 seconds]
<vagrantc>
megi: that's bearable
<lurchi__>
gnarface: for the cables no, just for the switch itself
<vagrantc>
thanks for the answers folks!
* vagrantc
waves
vagrantc has quit [Quit: leaving]
<megi>
out of tree patches for that though
<megi>
thermal regulation is not mainline, so you can forget 1.8GHz
<megi>
I have a really crazy HDMI cabling setup with a long cable from a digital HDMI switch to monitor and from various length random cables from aliexpress to individual boards and I haven't witnessed any issues
<megi>
but I'm not pushing the limits with 4k or whatever
<megi>
just regular FHD/60Hz
<karlp>
megi: they're gone...
<megi>
ah
<karlp>
last they saw was, "usb3 not in mailine"
<megi>
I only ever had weirdness with old analog signalling
<karlp>
they missed the "out of tree patches though"
<megi>
I know
<megi>
there's logs :)
<karlp>
so. is it worth trying to submit a .dts file to lkml/linux-sunxi that covers the wifi portions of a device, but ignores the bluetooth portiosn?
<megi>
yeah
<karlp>
I can totally confirm the wifi bits, but I'm massively struggling with trying to verify bluetooth
<megi>
I did that, and noone objected
<karlp>
ok. might try again. I posted v1 long time ago, and I'v ecleaned up bits since then,
<karlp>
should I be sending to both lkml and linmux-sunxi or _just_ linux-sunxi? who takes arch/arm/boot/dts?
<megi>
you should use get_maintainers.pl script
<megi>
call it with a patch as an argument
<megi>
and myabe add a sunxi mailing list too
<karlp>
alright.
<karlp>
bluetooth is givning me a headache, mostly because I don't have any _known working_ bluetooth hardware.
<megi>
is it not loading firmware, or is the issue later on?
<karlp>
honestly? no idea :) like I said, never had bt on linux, not sure what it should or shouldn't be doing :)
<karlp>
or, "am I just missing userspace shit?" no idea!
<karlp>
and I should "just" need to tweak the pins for my board, but I think I'm missing basic bluetooth knowledge, so I'd like to get the board itself out and let things more forwards.
<megi>
yeah, enabling bt is usually just about configuring the clock, enabling the right serial port, putting firmware in the right place, and maybe setting an address after it probes
<megi>
at this point, with those patches from wens
<karlp>
yeah, from the mailing list patches, and the dts changes I've seen, that's all it should be,
<karlp>
but I'm not prepared to try pushing them as I've got them, without having it working
<megi>
it should show in dmesg that fw is loaded, that way you'll know that it's communicating, etc.
<karlp>
but when my entire bluetooth sample set is this device, and it doesnt' work, *shrugs*
<karlp>
I see the fw being loaded for the wifi part,
<megi>
yeah
<megi>
you shou also see for bt
<karlp>
yeah, if I turned on all the right kernel options for it, and got all the right files in the right place in the rootfs.
<karlp>
that's the bit that's tedious
<megi>
yeah
<karlp>
it's not really depending on the dts at that point, just "arbitrary userspace shit"
<megi>
I don't really use BT, anyway, but userspace seems like it changed a lot over the years and it's hard to find non-outdated info
Wizzup has joined #linux-sunxi
<ullbeking>
thank you all for the very intersesting insight into HDMI cables. i'm please my question was not in vain, and actually brought some useful knowledge (for me at least) to the surface.
<karlp>
ullbeking: I'm still super concerned abotu gnarface's stories, because gnarface seems plausible, but I don't know the mechanism by which things could negotiate down to lower res.
<megi>
one thing I know is that some of these chips refuse to do anything if dmesg shows "Using default device address ..."
<ullbeking>
megi: i wouldn't even know what that message means
<megi>
I think BT device must have globally unique ID, just like ehternet cards have a MAC
<megi>
but some don't have it assigned
<megi>
and you have to provide it yourself
<megi>
until then the chip is disabled
<gnarface>
karlp: to be clear, i didn't see anything dropping resolution, just refresh rate, that i could confirm with software. the additional visual quality change was unexplained by either resolution or refresh rate changes, but was confirmed by a sort of ad-hoc "double blind" test, so i decided it must have been about video codec or something, as i had seen the codecs renegotiate under similar circumstances before
<gnarface>
- as i had seen the *audio* codecs renegotiate under similar circumstances before, i meant to say
<gnarface>
the DVR box isn't very forthcoming with debuggin information though. i didn't even figure out the 1080i/1080p thing until i plugged a raspberry pi into it
<megi>
karlp: btmgmt public-addr 00:03:19:9e:8b:00 may enable it
<gnarface>
karlp: oh unless you consider 1080i to 1080p to be the resolution change in question. in that case nevermind. yea i guess that would be considered different resolutions to the hardware
<gnarface>
(in my head "interlaced" versus "progressive" is a separate factor from resolution, but the hardware probably doesn't see it that way)
Danct12_ has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
Danct12_ has quit [Ping timeout: 265 seconds]
\\Mr_C\\ has joined #linux-sunxi
Danct12_ has joined #linux-sunxi
nashpa has quit [Ping timeout: 268 seconds]
Danct12_ has quit [Remote host closed the connection]
Danct12_ has joined #linux-sunxi
nashpa has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
dev1990 has quit [Ping timeout: 240 seconds]
dev1990 has joined #linux-sunxi
Danct12__ has joined #linux-sunxi
Danct12_ has quit [Ping timeout: 265 seconds]
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
Danct12__ has quit [Remote host closed the connection]
Danct12_ has joined #linux-sunxi
Danct12_ has quit [Remote host closed the connection]
megi has quit [Ping timeout: 276 seconds]
Danct12_ has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
Danct12_ has quit [Remote host closed the connection]
Danct12_ has joined #linux-sunxi
Danct12_ has quit [Read error: Connection reset by peer]
return0e has quit [Remote host closed the connection]
Gerwin_J has quit [Ping timeout: 264 seconds]
_whitelogger has joined #linux-sunxi
rexxster has joined #linux-sunxi
airwind has joined #linux-sunxi
<KotCzarny>
ffs, ethernet manages 100mbit over 100m without any boosters and packet loss
<KotCzarny>
stupid 'standards' overrengineered and underperforming
<KotCzarny>
2 pairs should be enough for everyone!
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
selfbg has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
return0e has joined #linux-sunxi
return0e has quit [Ping timeout: 268 seconds]
arete74 has quit [Ping timeout: 240 seconds]
return0e has joined #linux-sunxi
arete74 has joined #linux-sunxi
return0e has quit [Remote host closed the connection]
jernej has quit [Read error: Connection reset by peer]
jernej has joined #linux-sunxi
florian has joined #linux-sunxi
hlauer has joined #linux-sunxi
<hlauer>
Hi, the alsa driver sun4i-i2s.c changed in 5.3 and 5.4 versions, trying to tie together the hifiberry amp with the tas571x.c driver. Is there a simple platform driver with which I can try to compare the code for debugging ?
return0e has joined #linux-sunxi
arete74_ has quit [Ping timeout: 245 seconds]
return0e has quit [Ping timeout: 246 seconds]
arete74 has joined #linux-sunxi
ganbold has quit [Remote host closed the connection]
ldevulder_ is now known as ldevulder
tnovotny has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
<KotCzarny>
now you dont have to feel bad for your oranges ;)
<megi>
open tesla, pop in a new sd card, done
<fALSO>
LOL
<fALSO>
its a emmc
<fALSO>
and its probably not very acessibile
<megi>
I know, but if it was SD card...
<fALSO>
and the car wont charge LOL
<fALSO>
;-PPPPPPPPPPPPPP
<megi>
it would be user fixable
<fALSO>
they dont want the users to fix their cars
<fALSO>
they dont even sell parts
<KotCzarny>
if teslas were running on oranges they could simply go megi's way ;)
<megi>
user could buy on on aliexpress
<fALSO>
its like an apple thingy
<megi>
yes!
<fALSO>
"rent" the car
<fALSO>
its not yours
<megi>
you could even upgrade your tesla from H3 to H6 to go faster!
<fALSO>
lets wait until the batteries start dying
<KotCzarny>
vrOOm
<megi>
or get a kernel for your tesla from random people on the internets!
<fALSO>
KLOL
<fALSO>
with a patched engine.c
<fALSO>
moar horse power
ldevulder has quit [Quit: Leaving]
ldevulder has joined #linux-sunxi
aalm has quit [Quit: xyz 2.3]
chewitt has joined #linux-sunxi
ganbold has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
<KotCzarny>
you can also grab cvbs2usb grabber
<KotCzarny>
erm, wrong chan
ldevulder_ has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
ldevulder has quit [Ping timeout: 245 seconds]
BenG83 has joined #linux-sunxi
<ullbeking>
KotCzarny lol
<insep[m]>
grab a grabber
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
msev- has joined #linux-sunxi
florian_kc has joined #linux-sunxi
AneoX has joined #linux-sunxi
AneoX has quit [Ping timeout: 276 seconds]
TheSeven has quit [Ping timeout: 264 seconds]
AneoX has joined #linux-sunxi
TheSeven has joined #linux-sunxi
ldevulder_ is now known as ldevulder
jailbox has quit [Ping timeout: 265 seconds]
jailbox has joined #linux-sunxi
aalm has joined #linux-sunxi
bisbarn has quit [Quit: Konversation terminated!]
<ElBarto>
mhm, does Linux enable a regulator if always-on is set ?
<ElBarto>
some FreeBSD user reported that bank E on the A64-Olinuxino isn't powered up
<ElBarto>
and the aldo1 which power the bank doesn't have boot-on so u-boot doesn't enable it (same as the FreeBSD kernel)
<ElBarto>
he says that it's working in Armbian but I don't know if Armbian hacked some stuff or if the Linux kernel enable a regulator if only always-on is true
<mru>
always-on means enable at boot and never disable
<ElBarto>
it doesn't means at boot
<ElBarto>
regulator-always-on:
<ElBarto>
description: boolean, regulator should never be disabled
<hlauer>
codekipper: thanks for the repo. Trying to debug a hifiberry-amp platform module which works up to 5.2.x versions. The module loads but hw parms setup is never called. Any ideas how to debug ?
<codekipper>
what SoC?
reinforce has quit [Quit: Leaving.]
codekipper has quit [Ping timeout: 260 seconds]
<hlauer>
A20 - bananapro
vagrantc has joined #linux-sunxi
<libv>
but is the hifiberry not for rpi?
hlauer has quit [Ping timeout: 250 seconds]
codekipper has joined #linux-sunxi
<codekipper>
this shouldn't fail silently....do you have any logs?
<libv>
codekipper: hlauer dropped off
<libv>
he seems to be using hifiberry on a bananapro, which is an a20
<libv>
but afaict, hifiberry boards are for rpi
<libv>
and i do not know how compatible those connectors are
reinforce has joined #linux-sunxi
<codekipper>
If it's been working then the hardware setup is ok....I'll await logs it's beer o'clock now....so there's no rush.
<codekipper>
good to see you back policing the wiki!
<libv>
;)
<libv>
short haired big dude living in nuernberg, i think you can replace the word policing with something else ;p
<codekipper>
I stay polite online!
<libv>
;)
AneoX has quit [Ping timeout: 240 seconds]
AneoX has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
florian has quit [Quit: Leaving]
AneoX has quit [Ping timeout: 268 seconds]
florian_kc has quit [Ping timeout: 268 seconds]
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
dev1990 has joined #linux-sunxi
bisbarn has quit [Quit: Konversation terminated!]
Nyuutwo has joined #linux-sunxi
Nyuutwo has quit [Ping timeout: 268 seconds]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 264 seconds]
florian_kc has joined #linux-sunxi
hlauer has joined #linux-sunxi
florian_kc is now known as florian
warpme_ has quit [Quit: Connection closed for inactivity]