#linux-sunxi on 2021-03-16 — irc logs at freenode.irclog.whitequark.org

06:57 <gediz539> apritzel: tested DM_VIDEO with A13. looks nice. I did not see any problem.

06:59 <gediz539> using "CONFIG_VIDEO_LCD_MODE" settings for "a13-olinuxinom-lcd7.fex" from https://linux-sunxi.org/LCD page

07:00 <gediz539> now i'm trying to understand how to use CONFIG_LCD_ROTATION :)

07:26 <gediz539> rotation works like a charm, too.

07:27 <gediz539> just to note it down, i've done it with a quick and dirty way by appending a "uc_priv->rot = 3;" line in "sunxi_de_probe" function. just after "uc_priv->ysize = mode->yres;"

07:32 <gediz539> needless to say, "CONFIG_CONSOLE_ROTATION" should be also enabled

10:03 <apritzel> gediz539: re: CONFIG_CONSOLE_ROTATION> yes, as mentioned in the commit message this is the minimal patch to lift sunxi_display into DM_VIDEO land

10:03 <apritzel> gediz539: so happy to take a patch that adds this feature

10:05 <gediz539> apritzel: agree. DM_VIDEO has really great features.

10:06 <apritzel> gediz539: but also an amazingly long list of shortcomings

10:06 <apritzel> gediz539: you might for instance have seen the lack of a cursor

10:06 <apritzel> also the nifty boot logo is gone

10:07 <gediz539> yep. i thought missing boot logo was about me, not enabling BMP settings.

10:08 <apritzel> not really, you can load a picture via some command, but it's not the same, as it appears much later

10:09 <apritzel> I have some patch for the cursor, but not really convinced of it

10:12 <gediz539> is cursor patch sunxi specific or does it cover whole DM_VIDEO users?

10:13 <apritzel> gediz539: I wouldn't even know how to make this sunxi-specific, so it's for all

10:14 <gediz539> that sounds really cool

10:14 <apritzel> gediz539: I don't really understand how people can live without that, I would guess nobody use the video console in anger

10:15 <gediz539> apritzel: lol, you're right

10:15 <apritzel> Ashleee: so thanks for the report, this was a real bug: the SOPine card detect switch is active-high, where the Pine64-LTS (and all other boards, really) use active-low

10:16 <apritzel> gediz539: I mean typing somewhat works, but if you need to correct something, it get's really confusing

10:17 <gediz539> gives me the impression of somehow mistyping after enabling Insert mode

10:17 <apritzel> Ashleee: I will send a patch, if you tell me your email address, I put your Reported-by: in

10:18 <gediz539> but to be honest, I did not notice missing cursor until you told about that :D

10:19 <gediz539> so i may look into implementing a cfb_console like banner then, if there isn't anybody working on it

10:20 <gediz539> its even better to know that this feature would be useful not only for sunxi but also for all DM_VIDEO users

10:20 <apritzel> gediz539: please do, but maybe ask about this on the mailing list first, to get an agreement before you invest a lot of time

10:21 <gediz539> apritzel: thanks for the tip. i'll do that

10:21 <apritzel> there is some splash screen feature, but IIUC this replaces the whole screen, so it's more for end products

10:22 <apritzel> and there is this CMD_BMP command, which serves a similar purpose, but lacks compared to the old way

10:23 <apritzel> gediz539: Jagan had something related to a boot logo last year: http://u-boot.10912.n7.nabble.com/PATCH-v2-0-3-video-sunxi-Convert-DM-VIDEO-td416764.html

10:24 <apritzel> gediz539: but I am not convinced this was right

10:26 <gediz539> yeah i think splash screen is more like a placeholder until device fully boots

10:27 <gediz539> i didn't try DM_VIDEO with BMP cmd yet but if you say that it's not as good as the previous one i will pass it

10:27 <gediz539> i'll look into Jagan's commit then

10:28 <apritzel> honestly I think you shouldn't reinvent the wheel, so basing on top of BMP is probably the easiest

10:28 <apritzel> I think the main problem is that's it's too late, and there is no reserved space for the logo

10:29 <apritzel> IIRC in the the old way it was painted in the top left corner, as one of the first things, even before text output

10:30 <apritzel> now we have text in the top left corner, and can use the bmp command only at CONFIG_PREBOOT time

10:31 <apritzel> gediz539: but maybe fixing those two things would be much easier and more acceptable upstream

10:31 <gediz539> i'd use the fastest (hacky) solution it was only for myself

10:32 <apritzel> for instance we could just reserve some space for the bootlogo at the top left corner

10:32 <gediz539> but it looks like something everyone may use

10:32 <gediz539> so i'll give it a shot

10:33 <apritzel> then put the bmp command into the "preboot" environment variable, before "usb start"

10:33 <apritzel> this preboot solution comes basically for free

10:33 <apritzel> (just need to enter something into the .config/defconfig)

10:34 <apritzel> and reserving some rectangular area at the top doesn't sound like rocket science

10:34 <gediz539> not totally related but probably not irrelevant question -> did you have a chance to try true type fonts?

10:34 <gediz539> i could not compile it

10:35 <apritzel> gediz539: yes, I did, some time ago

10:35 <gediz539> and thinking about that, how to calculate the size of area when true type fonts are enabled?

10:36 <apritzel> but I was more happy with extending the bitmap font feature to allow bigger fonts, then use the kernel fonts (for instance sun12x22, which looks just awesome)

10:36 <KotCzarny> gediz539: i suspect you could learn a log from terminal emulators for X that implement ttf

10:36 <KotCzarny> *a lot

10:37 <apritzel> KotCzarny: there is already fully implemented TTF support in U-Boot

10:37 <apritzel> gediz539: ah, I actually uploaded some patches back then: https://github.com/apritzel/u-boot/commits/sunxi64-image-20180316

10:38 <gediz539> KotCzarny: does it look so obvious that i'm a total TTF illiterate person :)

10:38 <KotCzarny> apritzel: nice, do they support any font or just monospaced?

10:38 <KotCzarny> also, more importantly, is antialias supported?

10:38 <apritzel> KotCzarny: anything

10:38 <apritzel> KotCzarny: dunno about antialias, though

10:39 <apritzel> KotCzarny: but non-monospaces looks a bit awkward as a console

10:39 <apritzel> but I think it's not meant for that

10:39 <KotCzarny> yeah, it's related to my hint

10:40 <KotCzarny> without aa/hinting, ttf looks ugly as heck

10:42 <gediz539> apritzel: i will try to compile after applying your changes.

10:43 <gediz539> i get some errors like "undefined reference to `__aeabi_i2d'"

10:43 <apritzel> gediz539: keep in mind that those patches are three years old

10:43 <gediz539> KotCzarny: thanks for the hint btw

10:43 <apritzel> and most of them was just so that I could mimic the bootscreen of an old Sun workstation ;-)

10:44 <gediz539> sun12x22 is really aesthetic though :D

10:46 <apritzel> gediz539: Linux has even bigger fonts, partly based on that, partly from a different family

10:47 <apritzel> gediz539: I just see that most patches in this branch are useless or outdated, it's just the wider font feature that's useful, I think

10:48 <gediz539> there're probably lots of changes happened since then

10:49 <gediz539> so i will just try to fix my "__aeabi_dsub", "__aeabi_dmul", "__aeabi_dadd" errors

10:49 <gediz539> upgrading from gcc 7.5 to gcc 10 did not help

10:49 <apritzel> smells like floating point?

10:50 <apritzel> float-abi=hard, maybe?

10:50 <apritzel> I think all sunxi cores have FP

10:51 <gediz539> >float-abi=hard

10:51 <gediz539> i will try it

10:54 <karlp> make sure youre passing cpu flags to both compile and link?

10:59 <gediz539> is it right way to pass the flag to U-Boot "KCFLAGS=-mfloat-abi=hard"?

11:09 <karlp> no idea, I'm only used to similar errors frrom bare metal programming

11:11 <gediz539> oh okay. thanks.

11:12 <gediz539> looks like KCFLAGS works because i got "error: -mfloat-abi=soft and -mfloat-abi=hard may not be used together" when I've manually specified "-mfloat-abi=hard"

11:13 <gediz539> i'm obviously doing something wrong. i'll try to make it work with true type fonts.

11:13 <gediz539> apritzel: thanks again

11:22 <karlp> you can also get that if you are passing -L flags directly into the guts of a multilib toolchain root for instance?

12:07 <gediz539> right, I suppose :)

12:15 <apritzel> gediz539: karlp: but this is not about hacking U-Boot to somehow make it work

12:16 <apritzel> U-Boot probably has float-abi=soft for a reason, maybe it suppresses the use of FP deliberately?

12:17 <gediz539> i could not find where float-abi is set

12:18 <apritzel> gediz539: so it's your (cross-)compiler's default then, maybe?

12:19 <karlp> try setting it to soft explicitly, as hard didn't work ;)

12:21 <gediz539> apritzel: it was my initial thought too but $(CROSS_COMPILER)gcc -Q -v returns "... --with-arch=armv7-a --with-fpu=neon --with-float=hard ..."

12:22 <karlp> right, but uboot wants soft.

12:23 <gediz539> karlp: unfortunately same errors with "KCFLAGS=-mfloat-abi=soft"

12:30 <gediz539> which toolchain do you recommend?

12:45 <apritzel> gediz539: karlp: maybe check which other (ARM32) platforms enable TTF? and peek into their configs / Makefiles?

12:53 <gediz539> damn it

12:53 <gediz539> sorry for taking your time

12:53 <gediz539> it was mentioned in README.video

12:54 <gediz539> disabling "CONFIG_USE_PRIVATE_LIBGCC" is necessary to use true type fonts

12:56 <apritzel> smells like something for Kconfig to ensure

12:57 <apritzel> works for arm64 without it, btw

13:06 <apritzel> well, USE_PRIVATE_LIBGCC is always disabled on arm64, so that's why it works

13:11 <gediz539> i should've Read The Fabulous Manual in the first place but it'd be definitely better to check it automatically with Kconfig

13:13 <gediz539> great. now i see "ERROR : memory not allocated"

13:15 <apritzel> gediz539: don't blame yourself, I would say it's a Kconfig bug: if there is no user choice, then it should be enforced

13:15 <apritzel> gediz539: the ERROR at runtime?

13:15 <gediz539> yep. i got that error just after "usb start"

13:31 <gediz539> rotation and truetype fonts do not work together

13:32 <gediz539> anyway, truetype rendering looks neat

16:38 <jernej> whitequark irc log went crazy today, every line is trippled

16:39 <montjoie> it is backup

16:46 <jernej> apritzel: gediz539: regarding U-Boot output - I'm pretty sure colours are off currently. Most HDMI modes require limited range output, but I don't see any place where this would be handled.

17:13 <apritzel> jernej: I see the whitelogger nick three times in my user list ...

17:14 <apritzel> jernej: colours off: you mean for graphics/BMPs? Yeah, I think I've seen this as well, and somehow hacked around it back then

17:14 <apritzel> jernej: what do you mean with "limited range output", exactly?

17:52 <jernej> apritzel: I mean *all* colours, e.g. everything that HDMI outputs, including text

17:53 <jernej> apritzel: limited range means that in each RGB component is between 16 and 235

17:53 <jernej> you can read more here: https://referencehometheater.com/2014/commentary/rgb-full-vs-limited/

17:54 <jernej> this was very obvious during playback of http://jernej.libreelec.tv/videos/h264/2-APL%20Clipping.mp4 in Linux until I implemented automatic conversion to RGB limited when needed

17:55 <jernej> without conversion, you don't see any stripes

18:00 <apritzel> jernej: thanks, I see, will have a look later

18:01 <apritzel> I guess it doesn't matter for a pure black/white console

18:03 <jernej> depends, you are out of specs if you use 0-15 or 236-255

18:04 <jernej> but it's true that this should still be properly understood as black/white

18:08 <jernej> btw, someone should kick additional loggers...

19:05 <megi> martinayotte: try comparing the clocks for tcon in working/non-working kernel

19:07 <megi> it may be caused by commits d3472b94549fcc64d53b31b305b692169123d738 and b646fa326b9e5c3e097d316267603f24a859e68f

19:40 <megi> linux-sunxi is one of the first lists hosted at https://lists.linux.dev/

19:41 <martinayotte> megi: Where ? In DT ? It doesn't seems DT related because I've tested 5.7.y DT with 5.8 kernel. It seems to be in the code itself, but didn't get chance yet to build a new one without Armbian patches.

19:41 <megi> this page says there will be migration of subscribers https://www.kernel.org/lists-linux-dev.html but I'm not sure that will be the case for google groups lists

19:41 <martinayotte> megi: Do you personally have a PineBook-A64 ?

19:42 <megi> in debugfs

19:42 <megi> no, I don't

19:42 <megi> there's clks/clk_summary file there or something close to that path

19:50 <libv> megi: no mention on our google groups

19:50 <libv> i cannot even find "Konstantin Ryabitsev" on our mailing list it seems

19:51 <megi> it's quite new https://lwn.net/Articles/849441/

19:52 <libv> that does not make it less one-sided :)

19:54 <plaes> libv: IIRC this guy works for kernel.org

19:54 <apritzel> mripard asked for the the new sunxi list to be created

19:55 <apritzel> Konstantin is indeed the tool guy at kernel.org

19:58 <libv> again, that does not make it less one-sided

19:59 <apritzel> libv: what do you mean with "one-sided"?

20:01 <libv> usually, one would start a thread on the existing mailing list with "we can have a mailing list there, should we go there, what do we think?"

20:01 <libv> but then whatever.

20:02 <megi> that may still happen, that's why I noted the whole project was anounced today

20:02 <libv> err, sure.

20:04 <jernej> technically, sunxi platform has no dedicated ML set in kernel - google groups were rejected

20:05 <jernej> sending patches to google groups was thus never mandatory, just nice to do

20:05 <martinayotte> megi: I did "cat /sys/kernel/debug/clk/tcon*/clk_rate" on both 5.7.6 and 5.11.3, and they different ... tcon0/tonc1 ones are lower on 5.11.3 ...

20:06 <megi> 5.11.3 is non-working one?

20:08 <martinayotte> megi: do you have binaries handy from your 5.11 branch, it will speed me to figure out if the culprit is in armbian patches or something in your branch ? Yes, the 5.11.3 is the non-working (in fact the last armbian working was with 5.7.y, last summer I got the issue starting from 5.8.y, and all other branches since then)

20:09 <megi> I have binaries, but I'm pretty sure they will not run on pinebook, because of missing drivers

20:10 <megi> maybe you can try just reverting the commits I mentioned?

20:10 <martinayotte> True ... So, I guess I will have to do an Armbian build but without any Armbian patches ...

20:10 <martinayotte> Which commit ?

20:11 <megi> it may be caused by commits d3472b94549fcc64d53b31b305b692169123d738 and b646fa326b9e5c3e097d316267603f24a859e68f

20:12 <martinayotte> Ah ! Ok !

20:31 <martinayotte> megi: github doesn't find those commits ... Did you copy ids properly ?

20:57 <megi> it does for me, for example: https://github.com/megous/linux/commit/d3472b94549fcc64d53b31b305b692169123d738

21:04 <martinayotte> megi: Ok ! I was using "search" in github toolbar ... Anyway, those commits are from Feb. 15th, and since my issue is present since last August, I doubt it is related...

21:13 <megi> those commits are older

21:14 <megi> they are in my 5.8 and 5.9 kernels, too

21:14 <megi> they were not in 5.7

21:15 <megi> commit times are irrelevant, since they are in branches that get rebased often

21:29 <martinayotte> Ah ! Ok !