Wikiwide_ has joined #maemo-leste
Wikiwide_ has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
uvos has quit [Ping timeout: 264 seconds]
uvos has joined #maemo-leste
Pali has quit [Ping timeout: 268 seconds]
uvos has quit [Ping timeout: 268 seconds]
xmn has quit [Ping timeout: 268 seconds]
Wikiwide has quit [Remote host closed the connection]
Wikiwide_ has joined #maemo-leste
Wikiwide_ is now known as Wikiwide
ikmaak has quit [Ping timeout: 260 seconds]
ikmaak has joined #maemo-leste
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #maemo-leste
pere has quit [Ping timeout: 260 seconds]
scops has joined #maemo-leste
<scops> Hey :) i have a nexus5 to test maemo leste on... so if someone neets a (beta)tester; here i am ;)
pere has joined #maemo-leste
Pali has joined #maemo-leste
xmn has joined #maemo-leste
<Wizzup> scops: hi
System_Error has quit [Ping timeout: 276 seconds]
xmn has quit [Ping timeout: 268 seconds]
uvos has joined #maemo-leste
<uvos> scops: while Wizzup did briefly try leste on the nexus 5 we currently only really support the Motorola Droid 4, Motorola Droid Bionic, Pinephone and Nokia N900.
<Wizzup> scops: well, if you're interested in trying to make it work, it might not be super hard
<uvos> scops: as a conscious descision we decided to support only a handfull of devices untill our userspace is compleat as this limits the amount of time spend fiddeling with device spcific quirks
<uvos> however the nexus 5 has some mainline linux support
<uvos> so basic functionalty would not be to hard for someone to setup
<Wizzup> yeah the n5 should be quote doable
<uvos> yeah main problem would be someone to maintiain it
<uvos> we have the same problem with the pocophone f1, someone did a port but it cant be used because no one is here to maintain it.
<Wizzup> uvos: yes, but if scops is up for it, we can try, we'd just need to set up a way to boot from storage (usb), load kernel, and rootfs
<Wizzup> that might be enough to get a lot of things working
pere has quit [Ping timeout: 268 seconds]
_inky has quit [Ping timeout: 268 seconds]
<Wizzup> uvos: yeah so I again have the problem where my phone almost boots to h-d and then it just reboots itself, I think mce triggered
<Wizzup> this is definitely battery guard being too agressive - it's plugged into my laptop by cable
<uvos> Wizzup: this happens when you are below the threshold and your device is using more power than cpcap charger can draw from usb
<uvos> Wizzup: do you have charge-mode active?
<uvos> Wizzup: upower will then mark the battery as discarging and critcal and mce will shutdown
_inky has joined #maemo-leste
<Wizzup> no, I don't have charge mode atm
<uvos> well the way this is supposed to work is the device is supposed end up in charge-mode
<Wizzup> but it's weird because my device really had a lot of battery juice left
<Wizzup> like 30% or so
<Wizzup> so to find it shut down was a bit weird for sure
<uvos> without charge mode you can end up in a loop yeah
<uvos> regarding 30%
<uvos> is that callibrated value
<uvos> or just what upower claims using heuristic
<Wizzup> I'm pretty sure it should be
<Wizzup> I've been using it for months
<Wizzup> I can turn off the battery guard module
<Wizzup> I'd probably get 5-6 more hours out of it at least
<uvos> well on d4 the battery is callibrated only when the device has seen full charge ON THAT BOOT
<uvos> ok
<uvos> the alternatvie to the display lieing
<uvos> is the battery going lower than 3.3 v temporarly
<uvos> while it really has quite some charge left
<uvos> reasons for this:
<uvos> 1. the battery is dieing and its internal resitance is increasing rappidly
<uvos> 2. your contacts are corroded causing high contact resistance
<uvos> 3. you failed to screw down the contact with sufficant force
pere has joined #maemo-leste
<uvos> i reccomend montioring /sys/class/power_supply/battery/voltage_now
<uvos> it should not dip significantly when the device is under load
<Wizzup> well I can't atm check it since it reboots right away
<Wizzup> I really wonder if it's too sensitive
<Wizzup> I mean when I am -booting- it will maybe use more power than pc, but that won't -last-
<uvos> Wizzup: this is a different issue
<uvos> you have charge mode disabled
<uvos> it should end in charge mode
<uvos> mce is never involed in the boot to that
<Wizzup> well we don't have it enabled anywhere yet
<Wizzup> how do I enable it
<uvos> have it installed and add softlevel=charge-mode
<uvos> to cmdline
<uvos> just leave it in there for like 1 minute and then press the power button
sunshavi has quit [Read error: Connection reset by peer]
<scops> my main problem is time ;) i could easily test something... flash here and there, boot testbuilds (...) but i think i couldn't maintain a port for the n9 :( in general i'm very interessted in getting a modern maemo to more devices/users... i still have a old n810 laying around/playing with from time to time (yeah... i like the old maemo 4 ui more than the 5)
<scops> (my gnome setup looks a lot like diablo ;)
<Wizzup> scops: n9 or n5?
<Wizzup> nexus5 or nokia n9?
<scops> sorry... nexus 5... the nokia n9... will be in my hands in a few days. xD i think thats because i wrote n9 xD
sunshavi has joined #maemo-leste
<scops> i use Sailfish OS most of the time and wanted to look at meego to because my like for maemo xD
<scops> -to
<scops> +of xD
<Wizzup> how would you test the n5 image if we had one? using usb storage or something?
<Wizzup> or do you have some bootloader to load from emmc
<scops> hmmm if fastboot is an option to boot an image i could boot it with usb or flash it...
<Wizzup> I think I probably used fastboot at the time
<scops> atm there is crDroid installed on the n5
<scops> (just for testing)
<Wizzup> on usb
<Wizzup> but it was a pain, that I remember
<freemangordon> oh, ok, finally I found a way to flush scanout buffer changes to the display on d4
<freemangordon> calling drmModePageFlip on the same fb_id that is already attached to the crtcs seems to flush scanout buffer changes to the display
<Wizzup> :)
<freemangordon> yeah, this was driving me nuts :D
<freemangordon> yeaah, glmark is running
<freemangordon> this is with driver based on omap, but using gbm to allocate memory
<uvos> freemangordon: an update of the display is triggerd on DRM_IOCTL_MODE_DIRTYFB
<uvos> or DRM_IOCTL_MODE_PAGE_FLIP
<uvos> you could have just asked :P
<uvos> s/or/and
<freemangordon> uvos: well, you know that d4 display is not updated correctly, no?
<freemangordon> we've been discussing that for ages here
<uvos> not sure what you mean by updated correctly
<uvos> it is my understanding that modesetting calls PAGE_FLIP
<freemangordon> it does not
<freemangordon> it does that only for dri3 buffers
<freemangordon> ut not for 'main' scanout buffer
<freemangordon> *but
<freemangordon> so, the buffers sent through PRESENT are flipped, when on fullscreen
<uvos> ok
<uvos> .. but it works on plain omapdrm
<uvos> with accel none
<freemangordon> sure
<uvos> so it must call one of those or the display would never change
<uvos> this is the problem i had/have in the bootloader
<freemangordon> no, I think it used dumb buffers, not gbm ones
<freemangordon> *uses
<freemangordon> or some other difference
<uvos> sure but it sill hase to cause a flip
<freemangordon> anyway, I gave up on modesetting
<uvos> maybe strace it
<uvos> since it clearly dose cause one
<uvos> i do think creating a bespoke ddx is a mistake, moveing all of the device dependant stuff out of the displat server (regardless of if its implementing wayland or x11) is what is the goal of whole kms/drm refactoring of the linux video system
<uvos> but whatever floats your boat ofc
<freemangordon> uvos: see, I was all for having modesetting working, but it does not
<freemangordon> I mean - well, ok, we'll have dri3
<freemangordon> but, with missing rotation in kernel, it will be very time consuming task to implement it
<freemangordon> I already wasted too much time on that
<Wizzup> uvos: maybe it makes sense to do omap first, and then once that works well someone could look at making it work on modesetting
<freemangordon> mhm
<uvos> so did anyone talk to tomi yet - maybe implementing rotation in omapdrm isent so hard
<uvos> at least for tiler
<uvos> since its othewise supported by the kernel allready
<freemangordon> right now I see fluent 80 fps glmark2 in landscape
<uvos> what are you rotating with in your new ddx?
<uvos> gl
<uvos> ?
<freemangordon> no
<freemangordon> it is dri2
<freemangordon> video-omap
<uvos> on n900?
<freemangordon> and this is without HW accel
<freemangordon> no, on d4
<uvos> ok
<freemangordon> I will still need vrfb
<freemangordon> for omap3
<uvos> oh so your using tiler via the legacy omap specific ioctls?
<uvos> ok
<freemangordon> not really
<freemangordon> yes, I am using the tiler
<freemangordon> but not through ioctls
<freemangordon> omap_bo_create ahs special flags to return tiler addresses
<freemangordon> GBM bos does not
<freemangordon> hmm, wait
<freemangordon> oh, I think I know how to fix that
<freemangordon> but, have to think about it a bit more
<freemangordon> in general - bos allocated after we rotate, should be tiler bos
<freemangordon> anyway, gtg
<freemangordon> ttyl
<freemangordon> uvos: do you know which ioctl is used to rotate framebuffer?
<uvos> you rotate the plane
<uvos> part of the modifier interface
<uvos> altho modesetting must be doing something else
<freemangordon> ah, right
<uvos> since i dident find it useing it
<freemangordon> yeah, trying to find how exactly ms tries to rotate
<Wizzup> btw:
<Wizzup> $ rtcom-eventlogger-client --command count --service RTCOM_EL_SERVICE_SMS 2>&1 | grep 'Number'
<Wizzup> ** Message: 16:55:07.290: Number of events of service RTCOM_EL_SERVICE_SMS: 18132.
<Wizzup> that works at least
<freemangordon> did you copy DB from fremantle?
<Wizzup> yeah
<freemangordon> :)
<Wizzup> wow the rtcom-eventlogger-ui example is great!
<freemangordon> screenshot?
<freemangordon> ot there is no ui
<freemangordon> ?
<Wizzup> there is
<Wizzup> it's just all my personal stuff :)
<Wizzup> let me make one
<Wizzup> it's basically the phone view and conversations view
<freemangordon> ah
<Wizzup> of latest messages and calls
<Wizzup> including styles and everything
<freemangordon> nice
<Wizzup> yeah very fun
<Wizzup> freemangordon: https://wizzup.org/sms.png
<freemangordon> nice
<freemangordon> does it try to integrate with abook?
<Wizzup> yes
<Wizzup> I probably have old abook code though
<freemangordon> cool
<Wizzup> you just need ~/.rtcom-eventlogger/el-v1.db and then clone rtcom-eventlogger-ui and run the example
<Wizzup> this makes me wonder if rtcom-messaging-ui and rtcom-call-ui just use rtcom ui lib to render their stuff
<Wizzup> (and what we should do in qt...)
<freemangordon> :D
<Wizzup> as in, this is all gtk code
<Wizzup> it operates on gtk widgets, etc
<freemangordon> in theory we can use that
<freemangordon> from qt that is
<freemangordon> platform code already uses some hildon widgtes
<freemangordon> uvos: hmm, actually modesetting does not try to rotate through KMS, IIUC
<freemangordon> it uses shadow FB
<uvos> how dose it accelerate the transformation?
<freemangordon> I don;t think it does
<uvos> well that cant be right
<freemangordon> at least I can't find a way
<freemangordon> well, if you say so :)
<uvos> it cant be doing it in software only because there was a long standing bug in ms that was: software rotation fallback is broken and rotation only works on accelerated drm
<uvos> that was fixed semi recently
<freemangordon> I do;t see any rotation property being set on planes
<uvos> right i dident either
<freemangordon> uvos: if you find where/how it rotates in HW, please share
<freemangordon> all I see is 2 scanout pixmaps being created
<uvos> this is the commit that fixed sw rotation
<freemangordon> yes, I know that commit
<freemangordon> hmm, maybe rotation is not in modesetting?
<freemangordon> but somewhere else?
<uvos> no diea
<uvos> idea
<uvos> maybe ask on the xorg ml
<freemangordon> I don;t see that code (or anything similar) anywhere
<uvos> freemangordon: no idea
yanu_ has quit [Read error: Connection reset by peer]
<uvos> freemangordon: i also went and looked if i can find where sway/wlroots perform the rotation
<uvos> freemangordon: and cant find that either
<freemangordon> hmm
<freemangordon> but, does performance degrade when rotated?
<uvos> only a tiny bit in gears
<uvos> i suspect it might be rotating with gles or so
<freemangordon> glmark?
<uvos> glmark dosent run
<uvos> on my setup
<freemangordon> could you try with blobs?
<freemangordon> you said it works
<uvos> it did when i was runing the blobs
<freemangordon> ok, now, how to test here
<freemangordon> ?
<freemangordon> I mean - it segfaluts on me
<freemangordon> how to investigate?
<uvos> but im using chomeos mesa on the working wayland d4
<freemangordon> h,, dbgsym I guess
<uvos> maybe try on sway first
<uvos> i never tried to really use westion
<freemangordon> is it in the repos?
<uvos> no
<freemangordon> git link please
<uvos> you have to patch it, i sill use really old sway that worked fine with a single patch
<uvos> modern sway is more dificult
<uvos> i think tmlind has a repo somewhere
<freemangordon> well, lemme try with weston first then
<freemangordon> uvos: hmm, how to rotate weston?
<freemangordon> from ini?
<uvos> no idea
<uvos> wlroots has wrandr
yanu has joined #maemo-leste
<freemangordon> ok, lets first have it running
<freemangordon> segfaults with blobs here as well
<freemangordon> ok, seems weston 5 does not correctly support wayland protolcol
<bencoh> isn't it more or less the reference implementation?
<freemangordon> yes, it is
<uvos> not sure what you expect wayland implementation across the display servers is a total crapshot
<uvos> its like x11 in the early days with vendors implementing xservers
<freemangordon> it does not properly support xdg_wm_base protocol it seems
<freemangordon> uvos: finally was able to compile weston 6 and can tell you that glmark runs just fine there
<uvos> freemangordon: great
<uvos> so that extention explains why it works on sway
<uvos> not sure if westion dose hw rotation
<freemangordon> however I see one CPU usage of ~80%, which looks to me like soething is being copied
<uvos> dosent it use sw rendering in gerneal
<uvos> it use pixman
<uvos> yeah westion uses pixman
<freemangordon> mhm
<uvos> i would expect it to be bad
<freemangordon> so, the same as modesetting
<freemangordon> it is not
<uvos> hmm?
<freemangordon> on d4 that is
<uvos> fps wise?
<freemangordon> on n900 most-probably will be like snail :)
<freemangordon> still running
<uvos> well westion syle rendering is not ideal
<uvos> since it dose composing but composes stuff in sw.
<uvos> btw dose it support rotation?
<freemangordon> ies, I am running glmark in landscape
<freemangordon> but, in fullscreen, so no compositing should be involved
<uvos> yes
<uvos> ok is it faster in native orientation?
<freemangordon> still running in landscape :D
<uvos> ok ok
<uvos> you can run just one test of glmark you know :P
<freemangordon> will report once it is finished
<freemangordon> yes I know
<freemangordon> glmark2 Score: 59
<uvos> so do you know how westion perfroms the transformation?
<freemangordon> no
<uvos> ok
<freemangordon> running in native orientation
<freemangordon> what the?
<freemangordon> it is twice as slow?!?
<uvos> glmark has this issue
<mighty17[m]> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/omap4-panda-common.dtsi#L313-L328 about these pinmuxes, the locations seem to be same for me (as same omap4430) but in my muxset i do not have these hsusb_* for usb-otg, they're for other stuff https://github.com/Unlegacy-Android/android_kernel_ti_omap4/blob/3.0/common/arch/arm/mach-omap2/board-espresso-muxset-r03.c
<uvos> it renders stuff with more pixels
<uvos> in portrait
<uvos> (since the elements are bigger)
<uvos> like the horse
<freemangordon> yeah
<mighty17[m]> this'll probably cause issues with pins being set multiple issues (sorry for dropping in a running convo didnt realise)
<freemangordon> but still, fps is ~62
<freemangordon> for drm it is like 80 and above
<uvos> wierd
<freemangordon> not really, it seems it renders through GL
<uvos> heh
<uvos> thats a great score for llvmpipe
<freemangordon> no, this is not SW rendering
<freemangordon> it renders through PVR, for sure
<uvos> ok
<uvos> then not sure what you ment
<freemangordon> the point is that it glmark renders to offscreen texture and then weston wenders that to the framebuffer
<freemangordon> the same does glamor
<uvos> right
<freemangordon> but it seems weston does that even for full-screen
<uvos> ok
<uvos> but that dosent explain why rotation is slower anyhow ok so your not useing pixmap
<uvos> instead there is a gl backend to westion (til)
<uvos> *no rotation
<uvos> so i gues it rotates the surface using gl too?
<uvos> mighty17[m]: no idea sorry
<freemangordon> most-probably
<freemangordon> but, I confirm that 'my' pvr_dri works with WL as well
<freemangordon> OMG: glmark2 Score: 40
<freemangordon> n900 is 37 with -drm
<freemangordon> anyway, cooking, ttyl
<mighty17[m]> okay! i'll wait for tmlind
<uvos> mighty17[m]: so whats your state on the tab?
<uvos> mighty17[m]: wrt what works and what dosent
<mighty17[m]> freemangordon: do we have something for GL_EXT_read_format_bgra for wayland (ik you made one for x)
<sicelo> scops: i never actually used pre-Maemo 5, but i like what i see on pictures (both the UI and the actual hardware, especially N810)
<scops> i can shot some photos but atm my n810 looks like this one: https://faceted.files.wordpress.com/2008/09/okuda_preview.jpg ;)
<Wizzup> we have the okuda theme on leste
<scops> i know :) but maemo 5 and leste doesnt have this nice little dock on the left (yeah it eats much unnecessary screenspace and isn't really usefull on small devices...) which makes okuda really nice looking imho
<sicelo> man that's a mint looking n810!! wow
<sicelo> freemangordon: "but, I confirm that 'my' pvr_dri works with WL as well" - WL here is Weston 6?
<scops> <sicelo> "man that's a mint looking n810!!..." <- my second and current n810 is in similar condition, but the slide mounting is somewhat aged :( still a very nice little device.
<sicelo> what do you use it for :)
<scops> ebook reading from time to time, browser testing, testing own xmpp server configurations
<scops> but for practical usage... classical journal making, musik player and ebook reading is still the best usecases for a n810 imho
<scops> muisc... ^^
<scops> scops: music x.x
* sicelo likes
calebtheythem[m] has joined #maemo-leste
<sicelo> hello calebtheythem[m]
<calebtheythem[m]> o/ hiya!
<calebtheythem[m]> I'm hoping to get my hands on some device with a slideout keyboard, seems like they're hard to come by in the UK and I heard this is the place to be :D
<sicelo> they're older than your OP6, and much slower/resource-constrained :-)
<sicelo> and ... and ... PowerVR
<calebtheythem[m]> ahahaha ohno
<calebtheythem[m]> I just found out about the Motorola Photon Q, it doesn't seems to run mainline either /yet/
<uvos> Motorola Photon Q has a nicer case
<sicelo> i hope other members of this community have something to share about it ... these devices never landed in my part of the world.
<uvos> and is a tad faster than d4
<uvos> otherwise its very close to it
<uvos> porting mainline to the photon is likely not very usefull vs just using the droid
<uvos> also photon q has no sim card slot
<uvos> it has a solderd sim
<calebtheythem[m]> The snapdragon S4 in it already has at least some mainline support, the lack of sim slot is weird though
<calebtheythem[m]> apparently you can mod a sim slot in
<uvos> you can replace it by soldering a new on in there
<uvos> yeah
<Wizzup> calebtheythem[m]: if you plan to work on kernel stuff or stuff that helps leste somehow I could try to send you something depending on your location
<uvos> the s4 having mainline support dosent mean that mutch, omap4 support is great in mainline but geting the d4 working was (well still is) a lot of work regardless
<calebtheythem[m]> uvos: heh, yeah but that's the fun part ;P
<sicelo> uvos: just for some 'context' - calebtheythem[m] has done a lot of the work on the OP6
<uvos> also the phonon q is really rare i have one (but its broken atm sadly- have to investigate that)
<Wizzup> ah cool
<calebtheythem[m]> Wizzup: thanks! I'm in the UK, I'm not sure if/what I'd like to work on, I just honestly really love these phones with physical keyboards and HDMI ports
<uvos> calebtheythem[m]: so maybe help us with the d4 instead? :)
<uvos> d4 has all of that
<uvos> !
<Wizzup> scops: so if you have a way to load images on the nexus5 we could try to build something
<calebtheythem[m]> uvos: but PVR !
<uvos> calebtheythem[m]: we have pvr working and freemangordon is on the way of making it quite sustainable kernel version wise. but yeah granted
<calebtheythem[m]> hm it's a shame the photon Q seems so hard to come by, I've found one listing in the US which seems relatively cheap, if i can get it imported it seems too good to pass up
<calebtheythem[m]> uvos: with OSS drivers?
<scops> Wizzup: yeah :) like i said, with fastboot i can try directly.
<uvos> calebtheythem[m]: well no. kernel space is oss so is some of the userspace (implements mesa classic driver) but gsgl compiler and libgles is closed source.
<sicelo> calebtheythem[m]: if you get the photon q working, yay
<Wizzup> scops: let's see I have my 2019-02-02 usb rootfs here, which might have worked at some point, and also some hammerhead bootimg.cfg stuff
<uvos> yeah sure photon q would be neat just remember that its an old extreamly rare device with no sim card slot - so it will never be a widespread thing amoung users.
<calebtheythem[m]> uvos: ah, that's a shame re: pvr, it would be fun to work on the d4 where there's actual users XD.
M1peter10[m] has joined #maemo-leste
<uvos> we (or well Wizzup) have d4's in abundance so giveing you one would be no issue if you want to contribute :)
<MartijnBraam[m]> lol
<Wizzup> ^_^
<calebtheythem[m]> uvos: whoa, that would be super cool :D, I don't know that I could commit a lot of time but it would certainly be fun
<Wizzup> okay
<Wizzup> (dropped pm)
<Wizzup> tmlind: wonder if we can get more droid4s some way, maybe craigslist or a request on ebay or something
<calebtheythem[m]> got it!
<Wizzup> calebtheythem[m]: :)
<uvos> calebtheythem[m]: you dont happen to have knowlage on alsa asoc drivers do you?
<calebtheythem[m]> uvos: i've never dealt with the drivers im afraid, though i am working on the userspace crap at the minute
<uvos> OK
<Wizzup> what userspace?
<calebtheythem[m]> AOSP stuff for work
_inky has quit [Ping timeout: 256 seconds]
<Wizzup> *nod*
<calebtheythem[m]> sorry, i really hate audio stuff. its all android HALs built on top of tinyalsa, its a huge mess
<freemangordon> sicelo: yes, weston 6
<Wizzup> calebtheythem[m]: awwww I was hoping to ask you to help with audio :-p
<freemangordon> sicelo: isn;t that enough to confirm it is ok?
<sicelo> it is :-)
<freemangordon> Wizzup: parazyd: maybe we shall build mesa?
<sicelo> i was asking just to be sure ... can't play with my N900 for a while, but i plan to get back to it soon
<freemangordon> or, we want to have xorg drivers first?
<Wizzup> freemangordon: do you mean the pvr mesa?
<freemangordon> yeah
<Wizzup> maybe we repurpose the -experimental repo?
<uvos> i mean pvr mesa is fine in devel
<uvos> i should not interfear with ddk1.9
<freemangordon> uvos: are you sure?
<uvos> nor with the drivers pp uses
<freemangordon> ok
<uvos> freemangordon: pretty sure yeah
<calebtheythem[m]> Wizzup heh, sorry. ask away, i don't know ill be of much help though
<Wizzup> uvos: ok, so you're suggesting we merge it into out normal mesa?
<uvos> yes
<uvos> it should be fine
<uvos> ofc please try this first :P
<uvos> its just another classic mesa driver thats then unused
<uvos> so should have no side effects
<freemangordon> hmm, maybe we shall fix pvr driver not being loaded without MESA_LOADER_DRIVER_OVERRIDE=pvr first
<Wizzup> brb work mtg
<uvos> freemangordon: works for me with cromeos mesa
<Wizzup> calebtheythem[m]: it's mostly maemo specific audio stuff and some pulse stuff, so maybe not what android uses
<Wizzup> uvos has forbidden me to work on it much until the conversation stuff is going though :P
<uvos> heh
<calebtheythem[m]> ah i see, conversation stuff?
<uvos> calebtheythem[m]: sms/ip messaging
<calebtheythem[m]> oh right, cool. i need to read through your wiki pages
<uvos> we currently do have a sms ui but its bad
<uvos> and we want something that integrates sms and all kinds of ip messaging
<Wizzup> calebtheythem[m]: please let me know how painful it is to read the wiki, it's somewhat of a mess :)
<Wizzup> freemangordon: is the mesa pvr based on relatively recent mesa master?
<uvos> Wizzup: it applies to git
<uvos> Wizzup: so whatever you want
<Wizzup> ok
<uvos> at least cromeos pvr
<uvos> i doubt fmgs re is different in this regard
xmn has joined #maemo-leste
<Wizzup> uvos: got a link to the hp patches?
<Wizzup> I will try to apply them on 5.11
<freemangordon> Wizzup: My fixes are on top of chromeos fixes applied on top of leste mesa. IIUC
<Wizzup> freemangordon: got a link?
<Wizzup> freemangordon: also, what will be the next things to package - xorg server, and then?
<freemangordon> Wizzup: no, wait, why xorg server?
<Wizzup> ok, sorry, what else should I do?
<Wizzup> apart from mesa
<Wizzup> I thought you needed recent X for various fixes
<freemangordon> recent xorg was because of modesetting, but it is not working either ways
<Wizzup> ok
<freemangordon> so my last plan as of now is to have either omap or gbm based on omap driver
<Wizzup> ok
<Wizzup> that is xf86-video-omap ?
<freemangordon> I have omap driver working with ddk 1.17
<freemangordon> yes
<Wizzup> oh, sweet
<freemangordon> it needs some more fixes though, but I doubt those are complicated
<Wizzup> working is what exactly?
<freemangordon> everything
<freemangordon> but, dri2
<Wizzup> so h-d and stuff?
<freemangordon> h-d does not work so far because of the rotation, I have to investigate that
<Wizzup> ok, right, on the d4
<freemangordon> there is some assert failing
<freemangordon> the issue is when Xorg reinitializes the screen
<Wizzup> right
<freemangordon> Xorg: ../../../../include/privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed.
<freemangordon> this
<freemangordon> hmm, lets see what valgrind is going to say
<Wizzup> uvos: freemangordon: btw, the mesa linked doesn't seem to be based on latest mesa master? I think?
<Wizzup> or maybe I did not go far enough back in history
<Wizzup> it seems to be from 2020 december
<freemangordon> no, I think it is based on leste mesa
<freemangordon> but not sure
<uvos> yeah
<freemangordon> do you want me to rebase?
<Wizzup> really? latest leste mesa
<uvos> thats from leste upstream forks
<Wizzup> let me check
<uvos> but some time ago
<Wizzup> our master is from june 12 2021
<uvos> (whenever i first merged chomeos and leste)
<Wizzup> july*
<uvos> sure
<freemangordon> I'll rebase then, when I am back
<Wizzup> (and we should probably go for latest release)
<uvos> its fine tho it merged ok on git just 2 months ago or so
<uvos> (mesa git)
<Wizzup> maybe we rebase on 21.2.5 ?
<freemangordon> btw, isn;t it beta to get mesa from chimaera or even newer? but from debian, not from upstream
<freemangordon> *better
<uvos> no
<uvos> not really
<uvos> since we want the latest for the pp
<freemangordon> ah, ok
<Wizzup> yeah
<freemangordon> well, anyways I will be mia till tuesday, feel free to rebase for me
<Wizzup> have fun :)
<freemangordon> thanks
_inky has joined #maemo-leste
cockroach has joined #maemo-leste