07:22 tzimmermann: javierm, FYI i've sent out another update to the generic-fbdev patchset. each driver now selects a Kconfig option to opt into the default clients. it's rudimentary for now, but a later patchset will allow for fine-grained control of client support. i've recently discussed with jfalempe and found that there should be a DRM client library for drivers to use. as i'm going to mass-update all drivers here, i've added the
07:22 tzimmermann: Kconfig option now instead of doing another super-large patch series
07:38 javierm: tzimmermann: makes sense
07:40 tzimmermann: javierm, that other patchset will follow after this one got merged. i'll allow us to rework Kconfig hacks like the three selects at https://elixir.bootlin.com/linux/v6.11/source/drivers/gpu/drm/Kconfig#L12
07:41 tzimmermann: DRM_CLIENT_SELECTION will handle this
07:42 javierm: tzimmermann: oh I see. That's neat
07:43 javierm: tzimmermann: same for FB_CORE ? Since I guess not all client will needed (e.g: fbdev emulation will needed it but drmlog won't)
07:43 javierm: *need it
07:44 tzimmermann: yes, all three of them
07:44 jfalempe: tzimmermann: nice, I've made a small Proof of concept to load either drm_log or fbdev with a kernel command line parameter, it's based on your v4: https://github.com/kdj0c/linux/commit/61db6465963fce313ec0f56bda8088c0c0fb3abf
07:44 tzimmermann: kms_helper, fb_core and fb_sysmem_...
07:45 javierm: tzimmermann: cool. Thanks a lot for doing this refactor
07:45 javierm: jfalempe: I saw that in your weekly report. Nice!
07:47 jfalempe: I will rebase it on your v5, it should make it a bit cleaner.
07:49 tzimmermann: jfalempe, i see. all that would then be linked to the drm client-lib module
07:49 tzimmermann: is that the ideomatic way of building a menu in Kconfig?
07:50 jfalempe: I copied it from the zram compression Kconfig
07:51 jfalempe: But I found it provide good flexibility, and still ensure the selected default option will work.
07:52 javierm: tzimmermann: drivers/iommu/Kconfig also does the same
07:53 tzimmermann: ok.
07:55 tzimmermann: so if i don't hear anything, i'll merge my patch series at the end of the week
08:09 javierm: tzimmermann: you are not missing tags in any of the patches. I would say to go ahead and just merge it
08:10 javierm: specially since jfalempe has a patch series on top. Then he could post it to the list
08:11 tzimmermann: jfalempe's patch series needs to go onto the next series :)
09:11 jfalempe: Yes drm_log depends on write_thread() console patches. I will check if they are in drm-misc-next or not. I'm a bit lost how the different trees are merged together.
09:37 daddyblue: I have the preliminary smaller weighted power compressed 64 and 32bit value data sequenced access POC strategy, it has 5 variations, maybe more, but three of them avoid division by two. To be honest it tests my skills alot, it's pretty sophisticated to get used to.
09:38 daddyblue: It fits so much packed values that it should be the groundwork for modern file systems.
09:51 lumag: mlankhorst, tzimmermann: should we expect drm-misc-next-fixes pull? Is it ok to stuff fixes into that branch? Or we'd better use drm-misc-fixes?
09:52 daddyblue: But it does look like the community does not want to participate and i need help in testing or it would take ridiculously longer to land! So far i wiggled out from large errors i did at first, but too much work to do yet, i am getting success in accessing the elements, but as Peter Shor's quantum solver, i actually can not explain as to why it works so, he said it's too long to explain why
09:52 daddyblue: that works during an interview.
09:57 daddyblue: I tend to think it's under the hood, combinations that resolve in ieee1164 arithmetic core, cause you mix different + and - arithmetic, it takes some modulus there.
10:01 daddyblue: computation in jit decoded or encoded values, is lot simpler in concept, but as a maximalist i want to store a lot, and it has been holding me back, i am not so good at computation but have gotten the stored compressed sequences to work , need more testing.
10:04 daddyblue: I am actually forcing myself to work on this, cause i am very tired of this , i wished i did not manage this alone, i am not the brightest head alone.
10:18 daddyblue: the most interesting is multivalue access and filtering those values, this is achieved by maintaining the capacity of the hash, so cause 443+440 is 883 and this is eliminatable by -768-115 and the subtract from 1024, gives 141 which is a needed term.
10:20 daddyblue: this makes things very sophisticated next thing off, some addressing scheme needs to be chosen, similar to lba or chs.
10:34 tzimmermann: lumag, drm-misc-next-fixes is empty
10:34 tzimmermann: lumag, which fix do you have?
11:42 mlankhorst: lumag: it should go into drm-misc-fixes if it applies there, if it only applies to the next merge, it should go into misc-next-fixes
11:42 mlankhorst: after rc1, always drm-misc-fixes. :)
13:57 lumag: mlankhorst, thanks!
20:30 mareko: DavidHeidelberg: shouldn't this compile warning be suppressed? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/64059058
20:30 mareko: DavidHeidelberg: gcc thinks that uint8_t[16] is a string of maximum size 15
20:32 mareko: or I don't understand it