Wikiwide_ has joined #maemo-leste
uvos has quit [Ping timeout: 240 seconds]
Wikiwide_ has quit [Remote host closed the connection]
Wikiwide_ has joined #maemo-leste
cockroach has quit [Quit: leaving]
Pali has quit [Ping timeout: 240 seconds]
<rafael2k> Wizzup: nope, X from the repo
rafael2k has quit [Ping timeout: 240 seconds]
joerg has quit [Ping timeout: 240 seconds]
joerg has joined #maemo-leste
macros__ has joined #maemo-leste
macros_ has quit [Ping timeout: 268 seconds]
rafael2k has joined #maemo-leste
<rafael2k> Wizzup: lemme know how to test your setup today again
<rafael2k> morning
<rafael2k> no matter what it will break the package system, right? (just for me to be more well prepared this time)
Twig has joined #maemo-leste
mardy has joined #maemo-leste
<rafael2k> also, for the new pinephone kernel, please consider adding all the crypto stuff, luks and so on... I can not mount my PostMarketOS partition under Maemo kernel.
<rafael2k> btw, is maemo moving to chimaera?
calx has quit []
Twig has quit [Ping timeout: 256 seconds]
<freemangordon> Wizzup: which repo to use for non-CMA buffers parch?
<rafael2k> so, I'm not sure what changed in leste-config-pinephone / leste-config-common
<rafael2k> but it broke the audio in voice calls
xmn has quit [Quit: ZZZzzz…]
<rafael2k> I can see ucm2 directory have files changed...
<rafael2k> It seems some audio samplerate or other configuration mismatch, as I get some crazy noises in the phone...
<sicelo> rafael2k: i know at least pmos also saw audio breakage. apparently ucm loves to break things every now and then
<sicelo> maybe check what they had to do
<rafael2k> sicelo: well, this is related to latest config changes in leste-config-pinephone
<rafael2k> not related to alsa version change itself
<sicelo> ok
<rafael2k> I can see stuff at /usr/share/alsa/ucm2/sun50i-a64-audio was deleted
<rafael2k> pcm_slave.sl2 {
<rafael2k> pcm "hw:0,0"
<rafael2k> rate 88200
<rafael2k> }
<rafael2k> this sound suspicious too at 00_alsa_pinephone_dshare.conf
<rafael2k> HiFi audio playback is fine
<rafael2k> just VoiceCalls got trashed
<rafael2k> 1.54-1+2m7.1 was working fine
<rafael2k> 1.56-1+2m7 broke audio
<rafael2k> always when I think I have my Maemo all working, an update comes...
<rafael2k> :/
<rafael2k> lemme check in PmOS if calls audio is fine there
<rafael2k> in pmOS is still fine, I'll copy over the ucm2 and alsa config
Wikiwide_ has quit [Ping timeout: 256 seconds]
zhxt has joined #maemo-leste
<rafael2k> ok, the ucm2 files are corrupted
<rafael2k> (in maemo)
<rafael2k> I made the diff
<rafael2k> should I make a pull request?
mardy has quit [Read error: Connection reset by peer]
uvos has joined #maemo-leste
<rafael2k> found just the offending like
<rafael2k> making a pull request
<rafael2k> *line
mardy has joined #maemo-leste
<lel> rafael2k opened a pull request: https://github.com/maemo-leste/leste-config/pull/27 (fix voice calls in pinephone)
<rafael2k> uvos: sometimes the dialer does not open when I receive a call, also, is it normal that the dialer disapears just after a call is established?
<uvos> rafael2k: the dialer should close and the call ui should open allmost immidatly. the call ui is opened as soon as ofono registers the call and starts dialing, on mapphones this happens without any delay
<uvos> on the calls it dosent show up on please use ofono scripts to see if ofono is registering the call
<rafael2k> humm
<rafael2k> it does not show up
<rafael2k> right, ofono monitor will help me - btw - does sphone have no daemon?
<uvos> sphone is a deamon
<uvos> the desktop files just issue commands over dbus
<rafael2k> strange
<rafael2k> so this is why it is not showing up when I receive a call
<uvos> i dont know
<rafael2k> I think it is dying somewhere
<uvos> please run killall sphone; sphone -v -v
<rafael2k> ok
<uvos> open the dialer and place a call
<uvos> maybe it crashes
<rafael2k> should I run as root or user?
<uvos> user
<rafael2k> ok
<uvos> you can send the log to devnull@uvos.xyz if you dont want to paste it publicly
<uvos> or censor it
<uvos> (it will show the phone number)
<rafael2k> now it is working
<rafael2k> lemme play a bit more, it was after some time playing
<rafael2k> sphone: gui_history_list_double_click_callback
<rafael2k> sphone: gtk_gui_dialer_show: with +....
<rafael2k> this is something I found - the number does not show up
<rafael2k> ok
<rafael2k> then if I just press any key
<rafael2k> it shows (after I pick a number in recent)
<rafael2k> ok, found the real bug
<rafael2k> sphone: gui_calls_select_callback
<rafael2k> sphone: gui_calls_select_callback
<rafael2k> sphone: gui_calls_double_click_callback
<rafael2k> sphone: gui_calls_select_callback
<rafael2k> sphone: gui_calls_update_global_status: 1, 1
<rafael2k> (sphone:5037): GLib-GObject-CRITICAL **: 13:12:35.116: g_value_get_string: assertion 'G_VALUE_HOLDS_STRING (value)' failed
<rafael2k> when I was calling to it
<rafael2k> (receiving a call)
<uvos> and what where you doing to trigger this?
<uvos> besides a incomeing call
<rafael2k> I tapped in the hangup I think
<rafael2k> lemme try to repeat
<rafael2k> double tapped maybe
<rafael2k> then the UI closed and I could not really hangup the call
<uvos> did you accept the incomeing call first
<rafael2k> no
<rafael2k> I got a segmentation fault
<rafael2k> should have enabled core files
<rafael2k> :(
<rafael2k> no core created
<rafael2k> sphone-dbgsym ++
<rafael2k> ; )
<uvos> oh right i see the problem
<uvos> that bit isent implemented
<uvos> and its sending a null down the datapipe
<uvos> you clicked the remote pary name/ the remote phone number right?
<uvos> *party
Pali has joined #maemo-leste
<Wizzup> rafael2k: yo
<uvos> rafael2k: btw testing sphone is a lot eaiser if you add:
<uvos> [Modules]
<uvos> Modules=rtconf-libprofile;test;route-pulseaudio;playback-gstreamer;sphone-mce;comm-ofono;manager;external-exec;contacts-evolution;comm-error-gtk;contacts-ui-exec;store-rtcom;commtest
<Wizzup> rafael2k: we do plan to move to chimaera but it is a massive undertaking that we don't want to do just yet
<uvos> to a file called wahtever.conf in ~/.sphone/
<Wizzup> rafael2k: regarding X, just dpkg -i the packages I provided yesterday (only the ones I mentioned should be enough, otherwise add -dev ones as dpkg complains)
<Wizzup> rafael2k: when you then reboot and have X working still, let me know
<rafael2k> uvos: tks!
<freemangordon> Wizzup: thanks, will be on it as soon as I have some spare time
<freemangordon> BTW, is this boot fine on d4?
<rafael2k> uvos: where should I put this Modules line?
<freemangordon> *does this
<rafael2k> uvos: understood
<rafael2k> Wizzup: hey!
<uvos> rafael2k: a new file in ~/.sphone/
<uvos> dont forget the [Modules] section header
<Wizzup> freemangordon: should, yes
<rafael2k> Wizzup: ok! tks!
<freemangordon> ok
<rafael2k> uvos: did it
Twig has joined #maemo-leste
pere has quit [Ping timeout: 245 seconds]
Twig has quit [Ping timeout: 240 seconds]
<rafael2k> uvos: yes - I clicked remote phone number! will compile from source and keep testing
<Wizzup> tmlind: I don't feel like we're going to get a response from Nitin about the compaction
<Wizzup> maybe he's on holidays or something :)
Twig has joined #maemo-leste
<rafael2k> btw, I'm making sure eg25-manager works upstream without mm
<rafael2k> then we can create a package of it to the pinephone
<rafael2k> and remove the ad-hoc init scripts which bring up the modem
<Wizzup> what does it do?
Twig has quit [Ping timeout: 240 seconds]
dreamer has quit [Ping timeout: 260 seconds]
dreamer has joined #maemo-leste
<rafael2k> basically a modem daemon which sets the modem parameters and is used to properly suspend and resume the modem
<Wizzup> ok
Twig has joined #maemo-leste
<rafael2k> dunno if it isnt better to integrate in Maemo stach
<rafael2k> *stack
<parazyd> rafael2k: Nice! We already have a package so we can update it whenever you say.
<tmlind> Wizzup: yeah maybe he's oof
<tmlind> out of office
uvos has quit [Ping timeout: 240 seconds]
<rafael2k> parazyd: cool! did not know!
<rafael2k> the only difference will be the removal of libmm-glib-dev dependency
<rafael2k> and I just edited meson.build to require meson 0.49 instead of 0.50 (it builds fine with 0.49 from beowulf) in eg25-manager main
<rafael2k> (difference from a packaging perspective, I mean)
<rafael2k> parazyd: when you have time to create another pp kernel, lemme know, I can test
<parazyd> Will do
<rafael2k> also, concerning ofono for pp, lemme know how can I help
<rafael2k> I can work in building with internal libell if needed
<Wizzup> no, we can figure that out I think
<parazyd> Is our plan to use ofono-d4 for Pinephone as well?
<parazyd> Because otherwise we already have a build with ell
<Wizzup> parazyd: yeah I want to merge them
<parazyd> *nod*
<rafael2k> I based the debian dir of my repo in this repo https://github.com/maemo-leste-upstream-forks/ofono
<rafael2k> the ell files there are not enough for latest ofono as far as I could test
<rafael2k> but it is just a matter of copying files over...
<rafael2k> (from libell source)
sicelo_ has joined #maemo-leste
sicelo_ has joined #maemo-leste
mp1074 has quit [Quit: The Lounge - https://thelounge.chat]
mp107 has joined #maemo-leste
mp107 has quit [Client Quit]
mp107 has joined #maemo-leste
Twig has quit [Ping timeout: 240 seconds]
_inky has quit [Read error: Connection reset by peer]
inky_ has quit [Read error: Connection reset by peer]
inky_ has joined #maemo-leste
sunshavi_ has quit [Read error: Connection reset by peer]
_inky has joined #maemo-leste
sunshavi has joined #maemo-leste
uvos has joined #maemo-leste
sicelo_ has quit [Quit: Bye!]
sicelo_ has joined #maemo-leste
sicelo_ has quit [Changing host]
sicelo_ has joined #maemo-leste
<rafael2k> Wizzup: I did not forget about your X packages - will do it later today
<rafael2k> just trying figuring out if u-boot in pinephone already has the vol up / vol down to choose between what distro to boot (i'll do it between eMMC PMOS and Maemo in the SD)
<Wizzup> rafael2k: all good, I just want to confirm you're seing the same thing
<rafael2k> and figuring out how to see batery level
<rafael2k> is there a plugin for it in Maemo, right?
<Wizzup> it should just show yes
<rafael2k> hum
<rafael2k> it never really showed for me
<rafael2k> (since 10 years ago with the N900... eheheheh)
<Wizzup> right
<Wizzup> probably parazyd didn't pick up the patch I added to make sure upower sees the battery and exports the battery type
<sicelo> heh, on N900 Fremantle you couldn't see battery level? :-D
<bencoh> sounds like a crippled user experience :]
<freemangordon> parazyd: could you have a look at https://github.com/maemo-leste/liblocation/pull/1
<parazyd> Yes
Twig has joined #maemo-leste
Twig has quit [Ping timeout: 240 seconds]
xmn has joined #maemo-leste
sicelo_ has quit [Quit: Bye!]
sicelo_ has joined #maemo-leste
Twig has joined #maemo-leste
Twig has quit [Ping timeout: 268 seconds]
sicelo_ has quit [Quit: Bye!]
sicelo_ has joined #maemo-leste
sicelo_ has joined #maemo-leste
sicelo_ has quit [Changing host]
sicelo_ has quit [Client Quit]
sicelo_ has joined #maemo-leste
Twig has joined #maemo-leste
Twig has quit [Ping timeout: 250 seconds]
<Wizzup> uvos: do you recall how to use the qmimodem on the d4
<Wizzup> we had some other udev rules for it iirc
<rafael2k> sicelo: last time I saw the batery level -
<rafael2k> ( )
<rafael2k> : )
pere has joined #maemo-leste
Danct12 has quit [Remote host closed the connection]
<uvos> Wizzup: sure it uses the udev var OFONO_DRIVER
<uvos> Wizzup: just use udevadm info on the modem to figure out what to match against
<Wizzup> uvos: ok, might be good for some testing
<Wizzup> (to compare to motmdm)
<uvos> the ofono driver is called motorolamodem, but yes
<uvos> (just nit picking here in case you want to force it later)
<Wizzup> mhm
sicelo_ has quit [Quit: Bye!]
sicelo_ has joined #maemo-leste
sicelo_ has quit [Changing host]
sicelo_ has joined #maemo-leste
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #maemo-leste
mepy_ has joined #maemo-leste
<rafael2k> yay, the u-boot already shipped in maemo already has support for multi-boot using volume keys!
<rafael2k> ; ))
<rafael2k> _this_ is handy!
mepy has quit [Ping timeout: 240 seconds]
<Wizzup> :)
<rafael2k> now with volume_up I can boot the PmOS on the eMMC
<rafael2k> not having to open the phone and remove the SD to boot the eMMC is wonderful
alex1216 has joined #maemo-leste
<uvos> yeah having multiple boot entrys is very usefull
<uvos> i have like 10 :P
<uvos> i hate that android bootloaders dont allow this
<rafael2k> android per se is a plague
<rafael2k> current u-boot in pp supports at least 3 different boot entries, vol up, vol down, or no volume key pressed
<rafael2k> if test x$volume_key = xup ; then
<rafael2k> # choice when pressing volume up key
<rafael2k> else
<rafael2k> # choice when pressing volume down key
<rafael2k> elif test x$volume_key = xdown ; then
<rafael2k> # default choice
<rafael2k> fi
<rafael2k> crazy that I just discovered I already had the bootloader I need to multi-boot already installed...
<rafael2k> and thanks for the one who wrote this... https://leste.maemo.org/PinePhone
<rafael2k> mkimage -A arm -O linux -T script -C none -a 0 -e 0 -d boot.txt boot.scr
<rafael2k> this was the line I was looking for
sunshavi has quit [Ping timeout: 252 seconds]
<rafael2k> btw... if anyone can test (or trust in the tests / bisection I did): https://github.com/maemo-leste/leste-config/pull/27
<Wizzup> ok
<Wizzup> I'll merge it
<rafael2k> tks!
<rafael2k> Wizzup: could you pass me again the link the the x pacckages tarball?
<rafael2k> found
<Wizzup> rafael2k: sorry phone call
<Wizzup> rafael2k: ok, am here now
<rafael2k> no problem
<rafael2k> ; )
<rafael2k> ok, I'll stop for a bit trying to read network logs to see if MTS has VoLTE enabled or not
<rafael2k> :P
<rafael2k> yelp me
<rafael2k> install mesa first from repo
<rafael2k> (from experimental)
<Wizzup> I think you add experimental and just 'apt-get dist-upgrade'
<Wizzup> that should pull in mesa
<Wizzup> if it doesn't let me check my pinephone
<rafael2k> it worked
<rafael2k> installing the packages already
<rafael2k> concerning the X packages
<Wizzup> ok
<rafael2k> I should cherry pick just X (not overlapping with was just updated), without unneeded -devs right?
<rafael2k> done the dist-upgrade
<Wizzup> I think I gave you a list yeah
<Wizzup> well you need the -dev pkgs only if you have the -dev pkgs installed already at lower version
<rafael2k> there is stuff like xserver-common_1.20.13-3_all.deb and xserver-common_21.1.1-2_all.deb
<rafael2k> what should I install?
<Wizzup> wait, I send you 1.20 ones?
<Wizzup> remote all 1.20 debs
<Wizzup> remove*
<Wizzup> from the tar, if any
<rafael2k> yes
<rafael2k> many 1.20 mixed with 21.1.1
<rafael2k> ok
<BlagovestPetrov[> [offtopic] Guys, are there any requirements for writing "native" applications for Maemo? QML libs, etc?
<Wizzup> dsc_ has some experience with it
<Wizzup> rafael2k: if you want I can double check my tar
<rafael2k> dpkg -i libxcvt0_0.1.1-1+b1_arm64.deb libxi6_1.8-1_arm64.deb xdmx_1.20.13-3_arm64.deb xdmx-tools_1.20.13-3_arm64.deb xnest_21.1.1-2_arm64.deb xserver-common_21.1.1-2_all.deb xserver-xephyr_21.1.1-2_arm64.deb xserver-xorg-core_21.1.1-2_arm64.deb xserver-xorg-input-evdev_2.10.6-1_arm64.deb xserver-xorg-legacy_21.1.1-2_arm64.deb xvfb_21.1.1-2_arm64.deb
<Wizzup> rafael2k: I think you just need the three I suggested
<Wizzup> I don't think you need xnest or xephyr
<Wizzup> same for xdmx tools
<rafael2k> you never know
<rafael2k> :P
<Wizzup> ok
<rafael2k> I like X
<Wizzup> it might have more deps
<Wizzup> but you can try
<Wizzup> in any case xdms, xdmx-tools, xnest and xephyr you don't need
<Wizzup> xdmx*
<Wizzup> BlagovestPetrov[: conversations at least is a qml app that we have now
<rafael2k> gtk2!
<BlagovestPetrov[> :D
<BlagovestPetrov[> thanks. I'll check the conversations code :)
<rafael2k> just xserver-xephyr errored
<rafael2k> removed
<rafael2k> ok, all good
<Wizzup> rafael2k: ok, so you might want to turn on glaor
<Wizzup> glamor
<Wizzup> so not have accelmethod none
<rafael2k> ok
<dsc_> BlagovestPetrov[: QML works fine, I was going to make a bare bones sample QML project that people can extend and turn into their own project
<dsc_> generally its not different from other platforms
<rafael2k> ok, reboooting
<uvos> BlagovestPetrov[: the only toolkit that compleatly works atm is gtk2
<BlagovestPetrov[> understand.. but still, I'll try the qml
<BlagovestPetrov[> only the theming API in the newest qt quick controls is weird
<uvos> BlagovestPetrov[: qwidgets and qml is partally implemented, but lacks keyboard input and has some bugs with both stacked windows and qmenus
<Wizzup> what are the bugs with qmenus?
<BlagovestPetrov[> ah, ok
<dsc_> s/keyboard input/virtual keyboard input/
<uvos> Wizzup: the arrow is missing, there is a wierd timeing bug with the grab transfer
<dsc_> keyboard input works, at least for QLineEdit
<uvos> no
<uvos> it dosent
<rafael2k> BlagovestPetrov[: gtk2 + hildon
<uvos> keyboard vs xlib works
<rafael2k> Wizzup: up
<uvos> but not him
<uvos> ie it only works with physical keyboards
<rafael2k> crazy fonts
<rafael2k> very big
<BlagovestPetrov[> what is used for the keyboard, xvkbd or something from Nokia?
<Wizzup> rafael2k: ok, yeah
<rafael2k> ; ))
<uvos> rafael2k: you have to set the incorrect dpi of 96
<Wizzup> rafael2k: that is something I worked around in the /etc/init.d/xorg, it's unrelated to all of this
<rafael2k> good, I'll open a wine here to start enjoyng these font size
<Wizzup> it's just that my lab psu is not doing what I want it to do atm
<Wizzup> I think you just need to add -dpi 96 to the xorg options
<Wizzup> *think*
<uvos> you can do that
<dsc_> BlagovestPetrov[: as for QML performance, I can happily conclude that stuff like scrolling is pretty smooth on, for example, the Motorola Droid 4
<uvos> or you can set the size of the display in xorg conf
<Wizzup> yes, it is the easiest solution since we don't want to deal with this problem now at all
<uvos> so that 96 dpi results
<Wizzup> that works too
<rafael2k> right
<BlagovestPetrov[> :)
<Wizzup> rafael2k: in any case, portrait mode should be quite smooth for you I think
<Wizzup> landscape is not that fast, but it should be ok
<Wizzup> now, let me find the rendering issues that I saw
<rafael2k> this font size does not really bother me
<rafael2k> lets test the X
<Wizzup> rafael2k: well so what issues were you seeing before
<Wizzup> just to get a sense of what you think we were at before
amk has quit [Remote host closed the connection]
<rafael2k> X does not crash anymore, and I can see videos in youtube in firefox, but otherwise, the crazy annoying bug, for example, in firefox, which re-draws things randomly keeps going
<Wizzup> right
<Wizzup> so let's try something
<Wizzup> (booting my pp...)
<rafael2k> keyboard vkb letters show, then does not show, then shows again, then not
<Wizzup> yes, so let's test a potential 'fix'
amk has joined #maemo-leste
<Wizzup> rafael2k: btw, do you get portrait mode?
<rafael2k> indeed, taps are not precise also, which was not happening before
<rafael2k> I tap the vkb, and many "letters" are typed together
<Wizzup> rafael2k: that seems weird, I didn't see that, but it might be unrelated to the rendering problems
<rafael2k> I was using portrait
<rafael2k> lemme try landscape
<Wizzup> firefox runs in landscape for you?
<Wizzup> err portrait*
<rafael2k> landscape - I was talking about the terminal in that message
<uvos> forcerotation = 1 probubly
<rafael2k> firefox rotates to landscape when I open it
<uvos> makes the expirance better anyhow imo
<Wizzup> it doesn't matter so much, really, I just wanted to know if portrait was also smoother for you in say desktop scrolling
<Wizzup> rafael2k: right exactly
<Wizzup> rafael2k: that's good
<Wizzup> ok, so let's focus on the rendering stuff
<Wizzup> in /usr/share/hildon-desktop/shortcuts.ini
<Wizzup> add this:
<Wizzup> Unredirect=XF86AudioLowerVolume
<Wizzup> and maybe just remove whatever is assigned to any volume buttons
<uvos> rafael2k: set in /usr/share/hildon-desktop/transitions.ini forcerotation = 1 to allow anything to rotate
<Wizzup> uvos: this is not relevant atm
<rafael2k> ok
<uvos> Wizzup: if you say so
<Wizzup> rafael2k: if you made that change, you can now temporarily disable compositing for windows
<rafael2k> LeftButton=XF86AudioLowerVolume
<rafael2k> I already have this assigned...
<uvos> he also has to killall hildon-desktop
<Wizzup> rafael2k: so what I noticed is that if I hit that button when osso-xterm is active, and then raise vkb, it has no problems whatsoever
<Wizzup> rafael2k: so just remove that
<Wizzup> uvos: yes, I was getting to that
<rafael2k> ok
<Wizzup> rafael2k: keep in mind that this compositing disable is only temporary, it comes back when you return from vkb
<rafael2k> all changes done
<Wizzup> rafael2k: ok, so either reboot or killall hildon-desktop to refresh
<rafael2k> do you know where X is beeing called, to add the -dpi 96 ?
<Wizzup> /etc/init.d/xorg
<rafael2k> ok, killedall hilden-desktop
<rafael2k> nothing happens
<Wizzup> so now the lower volume button can be used to turn off compositing for an active window temporarily
<Wizzup> so open xterm
<Wizzup> and touch the screen
<Wizzup> you'll likely see vkb pop up and see artifacts
<Wizzup> right?
<rafael2k> the ui is frozen
<rafael2k> I'll kill X
<Wizzup> uh
<rafael2k> ok, not really frozen
<rafael2k> it just does not accept input anymore
<Wizzup> just reboot the device I think
<rafael2k> better
<uvos> xf86-input-libinput
<uvos> is a module
<uvos> that now wont load
<uvos> unles you have the ignore abi thing in xorg.conf
<uvos> we had that for some time and some old installs have left over files...
<Wizzup> uvos: the devices should come with evdev still
<Wizzup> I specifically provided him the .deb for that
<uvos> nopt
<uvos> nope
<Wizzup> is the case for mine
<Wizzup> fully up to date
<uvos> i moved all devices to libinput
<uvos> except n900
<Wizzup> in any case the input abi didn't change
<Wizzup> iirc
<Wizzup> just the video one
<uvos> yes it did
<uvos> input also changed
<uvos> for the gestures
<Wizzup> rafael2k: you said better, so I assume it works again?
<uvos> i gues tho that maybe xorg will try evdev if libimput dosent load
<uvos> but only if its installed
<Wizzup> I didn't have libinput on my device
<uvos> not sure if its an external module actually
* Wizzup trying to figure out why one of his lab power supplies now slowly builds up from 1V to 3.8V instead of going there directly
<Wizzup> must be some weird setting
<uvos> dose it hold against load at 3.8?
<rafael2k> it is working
<rafael2k> yes
<uvos> otherwise thats classic output transistor with a shorted base
<Wizzup> uvos: the led is at C.V instead of C.C
<Wizzup> uvos: it is likely a config option, the working one is at C.V
<rafael2k> and it did not crash yet
<Wizzup> rafael2k: ok, so let's try to do this again
<Wizzup> rafael2k: so I am not seeing any crashes, but I want to investigate the flickering/redrawing problems
<rafael2k> Wizzup: now I have sane font sizes
<Wizzup> first I'd like you to trigger that flicker/redraw bug
<Wizzup> and then we can see if you see the same as I do with the window 'un-composited'
<rafael2k> the fickering / redraw bug is exactly the same
<Wizzup> ok
<Wizzup> as expected
<Wizzup> do you reproduce this with osso-xterm?
<rafael2k> yes
<Wizzup> ok
<Wizzup> so now go to osso-xterm
<Wizzup> and press the volume down key
<Wizzup> the title bar of osso-xterm will change
<Wizzup> and then press the key again
<Wizzup> you should have a behaving vkb then
<uvos> huh
<uvos> yeah its wrong
<uvos> its switched over to libinput in leste config
<uvos> but the meta is wrong
<rafael2k> I press the volume down two times?
<Wizzup> uvos: btw I assume that fullscreen is also unredirected by default?
<Wizzup> rafael2k: just once does it for me
<uvos> Wizzup: its wierd and buggy
<uvos> sometimes it is
<uvos> sometimes it isent
<Wizzup> uvos: ok, let's exclude it from the test then
<Wizzup> rafael2k: just to check you did set the ini as I suggested right, the shortcuts?
<Wizzup> that is, this is present: Unredirect=XF86AudioLowerVolume
<Wizzup> and nothing else uses XF86AudioLowerVolume
mardy has quit [Quit: WeeChat 2.8]
<rafael2k> I'm not sure
<rafael2k> first time it seemed it got better
<rafael2k> yes yes, I set
<Wizzup> rafael2k: yes, it only lasts once
<Wizzup> you had to do it every time
<Wizzup> so if you see it was better the first time, then it worked
<Wizzup> now try it in firefox or something else
<rafael2k> wai
<rafael2k> wait
<rafael2k> testing this magic key in firefox
<rafael2k> much better
<Wizzup> right, so we know that compositing somehow causes this problem
<Wizzup> and looks like you're seeing the same as I am
<rafael2k> I mean, I could use like this
<rafael2k> it is fine
<Wizzup> (but good that the crashes are fixed, either with newer mesa or newer X)
<Wizzup> rafael2k: yes, but we can't just disable compositing :)
<rafael2k> why not?
<Wizzup> because then many parts just don't function anymore
<Wizzup> like the title bar
<rafael2k> now I want this "disabling compositing" too
<rafael2k> right, got it
<Wizzup> ok
<Wizzup> so what we need to do is either file a bug with hildon-desktop as example use case, or narrow it down further somehow
<rafael2k> I'm not really sure why we need it, but even my 11th gen intel with nvidia which can do raytracing, I always make sure I have this compositing disabled in my wm
<Wizzup> uvos suggested trying clutter demos
<rafael2k> :P
<Wizzup> rafael2k: hildon-desktop cannot work without compositing
<rafael2k> Wizzup: this is a bug in Mali driver...
<Wizzup> rafael2k: yes, it seems like that, in lima
<Wizzup> but hildon-desktop is not in normal debian distro, so if we file a bug it might be hard(er) to get developer to test
<rafael2k> lima, yes
<Wizzup> I'm just going to go to the channel and ask
<rafael2k> there are even gtk4 bugs opened in lima driver, I remember looking at them like 10 months ago
<rafael2k> the problem is certainly not with hildon...
<rafael2k> lemme find the opened bug report
<rafael2k> I sent it here like begining of 2021
<Wizzup> I don't think it is the job timeout bug though, is it?
<rafael2k> LIBGL_DEBUG=verbose GDK_DEBUG=opengl,gl-gles
<rafael2k> if we could grab some crazy messages from mesa debug...
<rafael2k> I think so
<Wizzup> we could, of course
<rafael2k> btw, vkb is not working anymore, it worked once, then never more showed up
<rafael2k> :/
<uvos> probubly makes more sense to first find something with the minimum draw calls that triggers this
<rafael2k> (after the upgrade)
<uvos> and then do that
<rafael2k> agreed
<uvos> side note: since we established its not glamor causing issues, but h-ds clutter rendering, the least performance impacting (still terrible) workaround would be to set GALIUM_DRIVER for just h-d instead of accelMethod=none
<uvos> since that breaks acceleration only for h-d instead of for everything
<rafael2k> it is clearly buggy, a couple of widgets already expose the issue
<Wizzup> doesn't that still mean that all transitions would be cpu?
<Wizzup> rafael2k: yeah so we need to try some other compositing window manager and perhaps put some widgets on top of each other perhaps
<uvos> Wizzup: yes it would still be terrible, only marginally better than accelMethod=none
<uvos> you gain video acceleration and xorg 2d accel
<uvos> and games
<Wizzup> I think it would be better to just get a bug filed and not bother with other workarounds imho
<rafael2k> then video playback is possible - this is good!
<Wizzup> I joined #lima on oftc irc
<uvos> sure, im just mentioning it for rafael2k and inky who both currently use the acellMethod=none path
<Wizzup> and left a wall of text explaining the bug
<Wizzup> oh, urgh, now my apt is unhappy because of X :-)
<Wizzup> will be fun to install stuff now
<rafael2k> Wizzup: eheheheh
* Wizzup just removes meta pkgs for now
<rafael2k> nothing bad happens, it is just scary to type "Yes I want to fuck up my system!" to apt
<rafael2k> fun in the end
<Wizzup> yeah it does that now because I marked hildon-meta as 'essential' :)
<Wizzup> uvos: so what, like compton with i3wm and windows on top of each other or something?
<uvos> Wizzup: i dont follow
<rafael2k> some simple sample to demonstrate the error, right?
<Wizzup> regarding more simple reproduce case
<uvos> more like just xorg and some clutter demo that shows it
<rafael2k> with all "LIBGL_DEBUG=verbose GDK_DEBUG=opengl,gl-gles" and other possible verbosity
<uvos> and strip that demo of draw calls untill it no longer shows the problem
<Wizzup> well I was hoping they could do some of the work
<Wizzup> uvos: so what tests did yiu recommend?
<Wizzup> because I only see clutter-1.0-tests
<Wizzup> which is not clutter 0.8
<Wizzup> (which is what we use)
<uvos> well you could test if 1.0 also exibits the problem with those, failing that im sure you can find some .8 demos or?
<uvos> those demos probubly where ported over
<uvos> so the git history maybe
<Wizzup> ok, I hope the tests don't expose random other problems that lead nowhere :P
<rafael2k> or we could just boot debian bullseye with xorg and demonstrate the problem?
<uvos> yeah but demostrate with what
<uvos> exactly
<Wizzup> rafael2k: if you can, please
<rafael2k> I'd try any gtk app and some wm like gnome
<Wizzup> the clutter tests are not at all interactive
<Wizzup> they jsut print 'ok'
<uvos> the toys
<uvos> i ment the toys
<uvos> not the unit tests
<Wizzup> what is the package name? I can't find it in apt
<rafael2k> in the end... one solution is just use the proprietary drivers...
<Wizzup> let's not for now
<rafael2k> (I'm the one fine with noaccel :P )
<Wizzup> searching for 'clutter toys' on google is extremely useful
<Wizzup> ...
<uvos> i dont think these are packaged
<uvos> but maybe im wrong
<uvos> no idea
<uvos> i would also try comption too
<uvos> since thats easy
<uvos> and elimites a problem with the offscreen pixmaps
<uvos> that are used for composition
<uvos> but i find this unlikely
<Wizzup> if i have compton running, then osso-xterm with the vkb doesn't show the problem
alex1216 has quit [Quit: WeeChat 2.3]
<uvos> ok not that then
<Wizzup> the problem is also not there with matchbox-window-manager, unsurprisingly I guess
<uvos> matchbox dosent do any rendering at all
<Wizzup> any particular toy you have in mind? and do I run it with compton?
<uvos> no, try them untill you find one that hopefully shows the issues
<uvos> no
<uvos> no comption
<uvos> just xorg
<uvos> or matchbox if you like
<Wizzup> I wonder if there are some mesa env vars we can try somehow
<Wizzup> like flush after every draw or something
<Wizzup> hmmm
<Wizzup> I see some issues when I do the following:
<Wizzup> add to:
<Wizzup> /etc/hildon-desktop.env
<Wizzup> export LIBGL_DEBUG=verbose
<Wizzup> export MESA_DEBUG=flush,incomplete_tex,incomplete_fbo
<Wizzup> export MESA_LOG_FILE=/tmp/hd.log
<Wizzup> Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=GL_NONE)
<Wizzup> Mesa: User error: GL_INVALID_ENUM in glGetTexParameteriv(pname=0x8191)
<Wizzup> Mesa: User error: GL_INVALID_ENUM in glEnable(GL_TEXTURE_2D)
<Wizzup> uvos: ^
<Wizzup> this seems to come fromcogl-texture
<Wizzup> the error doesn't show when I am just scrolling h-d
<Wizzup> I guess it might be worth testing with llvmpipe or something else in vm and see if the errors also occurs?
<Wizzup> freemangordon: any idea perhaps?
<Wizzup> mightr be a red herring
<Wizzup> uvos: another potential interesting test would be to pull out the old clutter 1.0 hd and see if it has the same problems
<Wizzup> but clutter 1.0 performs terribly
* Wizzup break time
<Wizzup> omg lol
<Wizzup> my messages never made it to lima :D
<Wizzup> rafael2k: what issues do you see in firefox
<uvos> dose clutter 1.0 still perform terribly
<uvos> or did it just hit the problem in the old ddk's where they ended up copying the frame on the cpu
<uvos> like gears
<Wizzup> uvos: most likely still performs terrible
<Wizzup> uvos: so they asked for apitrace
<Wizzup> and the virtual keyboard problems where stuff is not visible *disappears* under apitrace
<Wizzup> uvos: rafael2k: hey, did we actually try glamor with llvmpipe?
<Wizzup> or did we only try to disable glamor alltogether?
<uvos> glamor was disabled
<uvos> but its not glamors fault since it works on glamor
<uvos> whenever hildon is not rendering
<uvos> glamor dose _more_work
<Wizzup> firefox also has no glitches with apitrace
<uvos> ie when you disable composistion
<uvos> then glamor has more work to do
<Wizzup> I guess this counts as heisenbug then
<Wizzup> freemangordon: wouldn't mind to pick your brain on this tomorrow
<_inky> as another method to test things i can suggest trying to run frozen-bubble from debian repos. it'll require bt keyboard though.
<Wizzup> what do you see?