| Wizzup | tmlind: I just got 4 mz609 delivered to my home, so that's timely :) | 01:06 |
|---|---|---|
| freemangordon | Wizzup: I suspect this https://github.com/Debian/apt/commit/4fad7262291a8af1415fb9a3693678bd9610f0d6 | 08:48 |
| freemangordon | this: | 08:49 |
| freemangordon | user@devuan:~/git/hildon-application-manager$ git diff src/apt-worker.cc | 08:49 |
| freemangordon | diff --git a/src/apt-worker.cc b/src/apt-worker.cc | 08:49 |
| freemangordon | index cb6a567..4242bb9 100644 | 08:49 |
| freemangordon | --- a/src/apt-worker.cc | 08:49 |
| freemangordon | +++ b/src/apt-worker.cc | 08:49 |
| freemangordon | @@ -2315,7 +2315,7 @@ mark_for_install_1 (pkgCache::PkgIterator &pkg, int level) | 08:49 |
| freemangordon | pkgCache::PkgIterator InstPkg(cache,0); | 08:49 |
| freemangordon | 08:49 | |
| freemangordon | // See if there are direct matches (at the start of the list) | 08:49 |
| freemangordon | - for (; *Cur != 0 && (*Cur)->ParentPkg == P.Index(); Cur++) | 08:49 |
| freemangordon | + for (; *Cur != 0 && (*Cur)->ParentPkg == P.MapPointer(); Cur++) | 08:49 |
| freemangordon | { | 08:49 |
| freemangordon | pkgCache &pkgcache = cache.GetCache (); | 08:49 |
| freemangordon | pkgCache::PkgIterator Pkg(pkgcache, | 08:49 |
| freemangordon | makes it compile, but I am not 100% sure this is the correct fix | 08:49 |
| sicelo | and my wlan joy was shortlived - d4 failure to connect on first try is back :-) | 08:54 |
| freemangordon | as expected :) | 08:58 |
| Wizzup | freemangordon: ty | 09:50 |
| Wizzup | freemangordon: looks correct to me | 10:26 |
| Wizzup | freemangordon: btw, any thought on this? https://github.com/maemo-leste/hildon-application-manager/commit/fb07a532ddb8fa3f96880188e97e242f3e2c35cc | 10:36 |
| Wizzup | the comment in the commit specifically | 10:36 |
| freemangordon | Wizzup: why would it be deleted? | 11:11 |
| freemangordon | https://github.com/Debian/apt/blob/766b24b7f7484751950c76bc66d3d6cdeaf949a5/apt-private/private-install.cc#L210 | 11:11 |
| freemangordon | you have to delete it explicitly | 11:12 |
| Wizzup | ok | 11:14 |
| Wizzup | currently I'm trying to debug why apt-worker doesn't want to give package details, but unfortunately it looks like glib by default closes it's stderr instead of logging it to something sane | 11:16 |
| Wizzup | and the remove part (ham) crashes at a certain point so it doesn't log the stderr | 11:17 |
| Wizzup | all fun stuff | 11:17 |
| Wizzup | and running it under strace doesn't work as that makes sudo unhappy | 11:17 |
| Wizzup | looks like it has some define DEBUG | 11:18 |
| Wizzup | not that it gives -any- more info :) | 11:19 |
| Wizzup | lol, the DBG() caused some segfault in the DBG | 11:56 |
| Wizzup | great | 11:56 |
| freemangordon | valgrind? | 11:57 |
| freemangordon | Wizzup: also, re APT::Progress::PackageManagerProgressFd() - why not allocate on stack? | 11:58 |
| Wizzup | freemangordon: it's tricky, apt-worker takes commands only over pipes | 11:58 |
| Wizzup | and there's no tool to just interact with it, only via h-a-m | 11:58 |
| Wizzup | and h-a-m eats the stderr and glib has no way to spawn it without eating the stderr with this call | 11:58 |
| Wizzup | well it does, but our glib does not | 11:59 |
| Wizzup | so I've made apt-worker log to a file, but of coures that still doesn't work if it segfaults | 11:59 |
| Wizzup | and you can't strace it because then sudo will deny the sudo invocations | 11:59 |
| Wizzup | it's just a typical mess where I spend over an hour just trying to get the error message / crash | 11:59 |
| freemangordon | like: | 11:59 |
| freemangordon | APT::Progress::PackageManagerProgressFd progress_mgr(status_fd); | 11:59 |
| freemangordon | Pm->DoInstall (&progress_mgr); | 11:59 |
| Wizzup | but I am now mostly at that point: apt-worker: got req AUTOREMOVE/7/32 | 11:59 |
| Wizzup | apt-worker: sent resp AUTOREMOVE/7/4 | 11:59 |
| Wizzup | apt-worker: before handle request | 11:59 |
| Wizzup | apt-worker: handle_request | 11:59 |
| Wizzup | freemangordon: let me check what you mean | 12:00 |
| Wizzup | oh, instead of the new? | 12:00 |
| freemangordon | mhm | 12:00 |
| Wizzup | I'm just not at all proficient in C++ | 12:00 |
| freemangordon | heh :) | 12:00 |
| Wizzup | last time I did anything meaningful in it outside of Qt5 port was in uni | 12:00 |
| freemangordon | oh | 12:00 |
| Wizzup | I probably just copied that from libapt src | 12:00 |
| freemangordon | please, ask when you have concerns then | 12:01 |
| freemangordon | I am pretty much good in c++ | 12:01 |
| Wizzup | I am :P | 12:01 |
| freemangordon | ok | 12:01 |
| Wizzup | I will commit this | 12:01 |
| Wizzup | then I'm back to trying to figure out why apt worker crashes when asked for GET_PACKAGE_DETAILS/8/36 | 12:01 |
| freemangordon | what you can do is: put sleep(20) in main, start whatever needs to be started, then attach gdb | 12:02 |
| Wizzup | mmm | 12:02 |
| Wizzup | that's a good idea actually | 12:03 |
| freemangordon | or put sleep(20) that in the function that crashes | 12:03 |
| Wizzup | maybe write the pid to the log first | 12:03 |
| Wizzup | I don't know what crashes ;) | 12:03 |
| freemangordon | yeah, I know ;) | 12:03 |
| freemangordon | no need | 12:03 |
| freemangordon | ps -ef | 12:03 |
| Wizzup | lazy :) | 12:04 |
| freemangordon | the other option is to get a coredum[p | 12:04 |
| Wizzup | we probably really need to look into that | 12:04 |
| Wizzup | btw, now that I have you here | 12:05 |
| Wizzup | for chimaera you wanted 'testing' for users and 'devel' for us? | 12:05 |
| Wizzup | and also 'experimental' ? | 12:05 |
| Wizzup | Program received signal SIGSEGV, Segmentation fault. | 12:06 |
| Wizzup | 0x00007f75a58322a3 in metaIndex::~metaIndex (this=0x5652a69cf2c0, __in_chrg=<optimized out>) at ../apt-pkg/metaindex.cc:46 | 12:06 |
| Wizzup | 46../apt-pkg/metaindex.cc: No such file or directory. | 12:06 |
| Wizzup | there we go | 12:06 |
| freemangordon | Wizzup: yeah, I think that makes sense | 12:11 |
| Wizzup | ok, just getting the catalog uri breaks in him | 12:16 |
| Wizzup | great, now I have almost fixed this pesky bug | 12:16 |
| Wizzup | s/him/ham/ | 12:16 |
| Wizzup | freemangordon: around? | 13:15 |
| Wizzup | https://github.com/maemo-leste/hildon-application-manager/blob/master/src/apt-worker.cc#L3498 - this causes corruption it seems | 13:16 |
| Wizzup | commenting this line and ham is all happy | 13:16 |
| Wizzup | I suppose it's possible this pointer is owned by someone else, right? | 13:16 |
| Wizzup | freemangordon: yeah apt-pkg/sourcelist.cc seems to return a pointer from its own cache | 13:22 |
| * Wizzup commits | 13:22 | |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/406 :D | 13:24 |
| sicelo | joerg: yes, i made a mistake to say 50mA :-) | 13:46 |
| sicelo | and yeah, i use the datasheet a lot | 13:47 |
| freemangordon | Wizzup: there is no concept of 'ownership of a pointer' | 14:08 |
| Wizzup | freemangordon: in any case it should not free it | 14:11 |
| Wizzup | it's freeing internal libapt-pkg data/structure and this is what causes the crash later on | 14:11 |
| freemangordon | who initializes that? | 14:11 |
| Wizzup | it's from libapt | 14:12 |
| Wizzup | libapt-pkg | 14:12 |
| freemangordon | which call in our code? | 14:12 |
| freemangordon | this https://github.com/maemo-leste/hildon-application-manager/blob/master/src/apt-worker.cc#L3448 ? | 14:12 |
| Wizzup | freemangordon: yes, that sets the index ptr from the libapt cache | 14:16 |
| freemangordon | right | 14:17 |
| freemangordon | Wizzup: who and why introduced that delete Index? | 14:18 |
| freemangordon | also, what about this https://github.com/maemo-leste/hildon-application-manager/commit/befa42eba4679e9aca05f91cb9128068ede0f3af ? | 14:19 |
| freemangordon | and this https://github.com/maemo-leste/hildon-application-manager/commit/23f4f3dc0f13b87d0904536c61086dcf82f8d5d7 | 14:20 |
| Wizzup | freemangordon: the mydebsystem is gone | 14:20 |
| Wizzup | let me check the get_meta_info_key | 14:21 |
| Wizzup | freemangordon: that function is unused and it uses symbols that are private | 14:22 |
| Wizzup | (get_meta_info_key) | 14:22 |
| freemangordon | ok | 14:22 |
| Wizzup | ok, not entirely unused | 14:22 |
| Wizzup | I'll fix it | 14:23 |
| Wizzup | but this is not related | 14:23 |
| freemangordon | do you want help? | 14:24 |
| Wizzup | sure, so: | 14:25 |
| Wizzup | Release.gpg.info doesn't exist at all in my vm | 14:25 |
| Wizzup | it's probably deprecated | 14:25 |
| Wizzup | the interface it uses to find the file is private/gone | 14:25 |
| freemangordon | hmm | 14:25 |
| Wizzup | the only thing it does is read the file for a string, which seems hacky | 14:25 |
| Wizzup | so if we really want to implement this, we can just use IsTrusted() or something | 14:25 |
| freemangordon | wait | 14:26 |
| freemangordon | I think this is Nokia addition, most-probably | 14:26 |
| Wizzup | well the last was a bit too hasty | 14:26 |
| Wizzup | yes, it looks like it | 14:26 |
| Wizzup | without the file it's hard to see what it might be searching for | 14:26 |
| freemangordon | sec | 14:27 |
| freemangordon | Wizzup: do you know where this file lives? | 14:29 |
| Wizzup | freemangordon: no, try find / | grep Release.gpg.info | 14:30 |
| Wizzup | or whatever it is called | 14:30 |
| Wizzup | honestly it seems to me we should just remove this code | 14:31 |
| freemangordon | perhaps, but lets first see what it was used for | 14:31 |
| Wizzup | https://www.google.com/search?q="Release.gpg.info" | 14:31 |
| Wizzup | freemangordon: it was used for get_domain which returns DOMAIN_SIGNED and DOMAIN_UNSIGNED | 14:31 |
| freemangordon | and? why shall we remove that? | 14:32 |
| Wizzup | because it's nokia specific nonsense that we don't need | 14:32 |
| Wizzup | at least, that's what I understand | 14:33 |
| freemangordon | why do you think we won;t need that at some point? | 14:33 |
| freemangordon | I see no reason why shall we remove support for 'trusted' domains | 14:33 |
| Wizzup | what does trusted even mean | 14:33 |
| Wizzup | just note that it's not part of libapt-pkg: | 14:33 |
| Wizzup | #define DOMAIN_INVALID -1 | 14:33 |
| Wizzup | #define DOMAIN_UNSIGNED 0 | 14:33 |
| Wizzup | #define DOMAIN_SIGNED 1 | 14:33 |
| freemangordon | it means - 'provided by us' :D | 14:33 |
| freemangordon | yes, I know it is not | 14:34 |
| Wizzup | I don't think it makes sense to do it this way in any case, since it uses some non-standard file for it it seems | 14:34 |
| Wizzup | whatever apt-key trusts is what is trusted | 14:34 |
| Wizzup | if we want to give our repository a higher priority we can just use apt ways for this AFAIK | 14:34 |
| freemangordon | but, that's one of the ways to alarm alarm user if she installs some random .deb | 14:34 |
| Wizzup | I don't think so, is it? | 14:35 |
| freemangordon | I think so | 14:35 |
| freemangordon | ok, lets just have that as #ifdef | 14:35 |
| freemangordon | don;t remove it | 14:35 |
| Wizzup | ok | 14:37 |
| Wizzup | in any case a deb release index has IsTrusted() for this purpose | 14:37 |
| Wizzup | so whatever 'domain' they invented doesn't seem particularly sensible imo | 14:37 |
| Wizzup | freemangordon: something else, do you know if it is possible to scale gtk bg_pixmap ? | 14:38 |
| Wizzup | https://github.com/maemo-leste/hildon-application-manager/blob/master/src/main.cc#L71 here | 14:38 |
| freemangordon | yes, sec | 14:40 |
| freemangordon | Wizzup: https://github.com/maemo-leste/osso-systemui-tklock/blob/master/visual-tklock.c#L784 | 14:43 |
| freemangordon | I can fix that | 14:43 |
| Wizzup | ok | 14:43 |
| freemangordon | ok, will do later today | 14:44 |
| Wizzup | freemangordon: btw buzz reported this but the 'recent contacts' screen in addressbook doesn't work well when you click on a recent contact | 15:10 |
| Wizzup | sorry, he didn't report this as an issue, but told me a few days ago | 15:10 |
| Wizzup | not urgent ofc | 15:10 |
| freemangordon | sure it does not, it relies on rtcom db | 15:11 |
| freemangordon | so, whoever calls rtcom-eventlogger shall be fixed | 15:12 |
| Wizzup | it loads data | 15:13 |
| Wizzup | but if you click on a person, it doesn't let you do anything with them, like make a new contact | 15:13 |
| freemangordon | yes, I know | 15:14 |
| Wizzup | ok | 15:14 |
| freemangordon | this is because rtcom-el db lacks the needed data | 15:14 |
| freemangordon | Wizzup: https://github.com/maemo-leste/osso-addressbook/blob/master/src/osso-abook-recent-view.c#L249 | 15:15 |
| Wizzup | I'm thinking we can upscale our theme backgrounds with AI: https://wizzup.org/wallpaper1_upscaled.png | 15:35 |
| Wizzup | thoughts? | 15:35 |
| Wizzup | orig is https://wizzup.org/wallpaper1.png | 15:35 |
| Wizzup | it might use more ram, although I think h-d should scale it to the display size? | 15:36 |
| freemangordon | it already scales | 15:37 |
| freemangordon | like, this is done in GPU | 15:37 |
| Wizzup | freemangordon: yes but we scale *up* from 800x480 | 15:37 |
| freemangordon | right | 15:37 |
| Wizzup | it's better to scale *down* from higher res to our screen | 15:37 |
| freemangordon | oh, no | 15:37 |
| freemangordon | downscaling is baaaad | 15:38 |
| Wizzup | well the current way we have nasty artifacts | 15:38 |
| freemangordon | where? | 15:38 |
| Wizzup | just look at it on a non-n900 screen | 15:38 |
| Wizzup | anything larger than 800x480, it looks ugly | 15:38 |
| freemangordon | I am looking ATM | 15:38 |
| freemangordon | in VM | 15:38 |
| freemangordon | and d4 | 15:38 |
| freemangordon | lemme change the background | 15:39 |
| Wizzup | try beta | 15:39 |
| Wizzup | but, you don't need to verify, you can know theoretically it'll be ugly | 15:39 |
| freemangordon | I was using beta all the time, but ok, lemme install it | 15:39 |
| freemangordon | hmm, why it is not in my VM | 15:40 |
| freemangordon | what the? where is my beta theme?!? | 15:41 |
| freemangordon | looks perfect to me | 15:42 |
| freemangordon | do you want screenshots to show me what do you mean by artifact? | 15:43 |
| freemangordon | do you mean those thongs on the edges? | 15:43 |
| freemangordon | *things | 15:43 |
| Wizzup | it cannot look perfect unless you have the vm size set to 800x480 | 15:44 |
| freemangordon | I am looking in the VM | 15:44 |
| Wizzup | it cannot make up pixels | 15:44 |
| freemangordon | it is not 800x600 | 15:44 |
| freemangordon | VGA-1 connected primary 1280x720 | 15:44 |
| Wizzup | it looks blurry and unpretty | 15:44 |
| Wizzup | I'll give you some before/after screenshots | 15:45 |
| freemangordon | it could be because of the way we upsample | 15:45 |
| Wizzup | there is just no way to make it not have artifacts | 15:45 |
| freemangordon | but, down-sampling always produce more noise/artifacts than up-sampling | 15:46 |
| freemangordon | also, unless we want to distribute pics for every possible resolution, I don;t think we can ever have non-blurry background | 15:47 |
| freemangordon | anyway, lemme finish what I am doing with HAM | 15:47 |
| Wizzup | I don't think is accurate | 15:47 |
| Wizzup | think this is* | 15:47 |
| Wizzup | downsampling with bicubic or lanczos is actually very good | 15:49 |
| freemangordon | as is up-samplin | 15:50 |
| freemangordon | I just think we use some lame up-sampling algo ATM | 15:50 |
| freemangordon | will check later on | 15:50 |
| Wizzup | freemangordon: I am not sure if you get my point, but cannot do upsampling better than downsampling, unless it's an exact factor 2x, 3, etc | 15:54 |
| Wizzup | what I was saying is that we can leverage neural network / ai upsamplers that use AI to create high definition images of low res ones | 15:54 |
| freemangordon | yes, I understand, but I think downsampling those on the device result in worse image than upsampling | 15:55 |
| freemangordon | *will result | 15:55 |
| freemangordon | anyway, please, lemme finish with HAM first :) | 15:56 |
| freemangordon | almost there | 15:56 |
| Wizzup | I think that means that the downsampling that is being used is wretchen then | 15:56 |
| Wizzup | sure :) | 15:56 |
| Wizzup | wretched* | 15:56 |
| Wizzup | https://wizzup.org/dirlist/maemo-leste/theme-upsample/beta/screenshots/ | 16:00 |
| Wizzup | notice the sawtooth | 16:01 |
| uvos__ | downsampling for sure can get better results than upsampling | 16:01 |
| uvos__ | especcaly when downsampling far | 16:01 |
| uvos__ | ie >4x | 16:01 |
| uvos__ | downsampling just a bit can have bad artifacts, this is true | 16:01 |
| Wizzup | https://wizzup.org/dirlist/maemo-leste/theme-upsample/beta/pngs/ here is the 'input' | 16:01 |
| uvos__ | those look good | 16:02 |
| Wizzup | those are just normal from the theme and AI upscaled | 16:02 |
| Wizzup | the screenshots are them loaded in my qemu | 16:02 |
| Wizzup | https://wizzup.org/dirlist/maemo-leste/theme-upsample/beta/pkg/ here is the pkg with 'hd' | 16:03 |
| freemangordon | Wizzup: I think what we can do is to have different backgrounds per aspect ration | 16:03 |
| freemangordon | *ratio | 16:03 |
| Wizzup | freemangordon: what we should do is have larger input images than the native screen res | 16:03 |
| uvos__ | i mean all current devices besides the pocophone are 16:9 no? | 16:03 |
| uvos__ | so atm its not a problem | 16:03 |
| Wizzup | the d4 and n900 already have the same aspect ratio and it still looks ugly | 16:03 |
| Wizzup | (on the d4) | 16:04 |
| freemangordon | how's that? | 16:04 |
| Wizzup | https://wizzup.org/dirlist/maemo-leste/theme-upsample/beta/pkg/ here is also the 8.5 pkg | 16:04 |
| uvos__ | i can confirm it looks terrible | 16:04 |
| Wizzup | freemangordon: you can see upscaling artifacts | 16:04 |
| freemangordon | ok, but I still think this is because bad algo | 16:04 |
| uvos__ | besides artifacts its also blurry | 16:04 |
| uvos__ | this you cant fix | 16:04 |
| freemangordon | background quality was the last thing I cared back then | 16:04 |
| Wizzup | freemangordon: sure it doesn't matter that much, I'm just surprised you think it's worse to have a 4x upscale | 16:05 |
| Wizzup | and then downscale it | 16:05 |
| Wizzup | as opposed to upscale from missing data | 16:05 |
| freemangordon | it is, because n900 will do this, most of the times ;) | 16:05 |
| freemangordon | like, if you throuw som h-d image on it to downscale | 16:05 |
| freemangordon | *throw | 16:05 |
| freemangordon | anyway, ttyl, HAM :) | 16:06 |
| uvos__ | not sure why the n900 doing it matters | 16:06 |
| Wizzup | uvos__: I think he means fremantle | 16:06 |
| uvos__ | just cache the image | 16:06 |
| freemangordon | no, I mean n900 | 16:07 |
| freemangordon | oh, wait | 16:07 |
| uvos__ | what about it then? | 16:07 |
| freemangordon | can't we scale just once, per device? | 16:07 |
| freemangordon | during install or theme/background being selected? | 16:07 |
| uvos__ | isent that what happens anyhow (with backgrounds at least) | 16:08 |
| uvos__ | surely they thought of someone applying a dslr image | 16:08 |
| freemangordon | not sure | 16:08 |
| Wizzup | I think they get cached/stored yes | 16:08 |
| uvos__ | otherwise n900 would die if you apply a 22mpix dslr image :P | 16:08 |
| freemangordon | ok, we can cache upscaled images then | 16:09 |
| uvos__ | *downsampled | 16:09 |
| freemangordon | upscaled with UI, or whatever | 16:09 |
| freemangordon | no | 16:09 |
| freemangordon | upsampled with that AI | 16:09 |
| Wizzup | https://wizzup.org/dirlist/maemo-leste/theme-upsample/beta/d4/ | 16:12 |
| Wizzup | you can see it is less grainy this way | 16:12 |
| freemangordon | Wizzup: ok, I agree, I just don't want to do unneeded upsample->downsample | 16:12 |
| freemangordon | lets just upsample once with th eappropriate algo when the cache is created | 16:13 |
| uvos__ | freemangordon: we dont want to upsample on device at all | 16:15 |
| uvos__ | just in the package | 16:15 |
| uvos__ | upsampling on device makes no sense | 16:15 |
| uvos__ | (ai upsampling is expensive) | 16:15 |
| freemangordon | it is not an issue if we do it only once when a particularimage is selected | 16:16 |
| freemangordon | changing theme/background takes time anyways | 16:16 |
| uvos__ | not sure what algo Wizzup used but most implementations need huge libaries like libtorch | 16:16 |
| freemangordon | if it is going to take 4 or 5 seconds does not matter | 16:16 |
| uvos__ | that we def dont want on device at all | 16:16 |
| uvos__ | and could take mintues on device | 16:16 |
| freemangordon | hmm | 16:17 |
| uvos__ | libtorch is like 400mb :P | 16:17 |
| freemangordon | ok, ok | 16:17 |
| uvos__ | you dont want that on device | 16:17 |
| freemangordon | yeah | 16:17 |
| Wizzup | (sorry, back in a bit) | 16:24 |
| * BlagovestPetrov4 uploaded an image: (63KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.petrovs.info/OeBbRfzKWMrNYfoVCmNanupL/IMG_20221215_173154840.jpg > | 16:32 | |
| * BlagovestPetrov4 uploaded an image: (67KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.petrovs.info/xlXqWDTiWWnFmVywetqcCRgZ/IMG_20221215_173145569.jpg > | 16:32 | |
| BlagovestPetrov4 | it needs a package with custom udev rules :)) | 16:32 |
| BlagovestPetrov4 | Wizzup: | 16:33 |
| Wizzup | is this the lapdock? | 16:33 |
| BlagovestPetrov4 | yes | 16:33 |
| Wizzup | cool! | 16:33 |
| BlagovestPetrov4 | and something should disable the screen locking | 16:34 |
| Wizzup | BlagovestPetrov4: you can do this from settings | 16:36 |
| Wizzup | or install simple brightness applet and set it to never disable the screen | 16:36 |
| Wizzup | freemangordon: did you mean to say "let's up or downsample once when the cache is created" ? | 16:37 |
| freemangordon | yes | 16:37 |
| BlagovestPetrov4 | I'll build a custom package with udev rules this weekend :) | 16:37 |
| Wizzup | BlagovestPetrov4: I think it makes sense to think about how this would work, and how switching is done | 16:39 |
| BlagovestPetrov4 | exactly. Udev will detect the exact hardware IDs and execute a script with xrandr | 16:40 |
| Wizzup | ok, let's see it :p | 16:41 |
| BlagovestPetrov4 | it may also need eventual remapping of the keys because the keyboard doesn't have function keys | 16:41 |
| Wizzup | BlagovestPetrov4: it doesn't look like hildon-desktop really does the right thing, for example the apps launcher only draws in a part of the screen | 16:43 |
| sicelo | yes udev seems best way to handle this | 16:45 |
| BlagovestPetrov4 | isn't it the same behavior as in the x86 image? | 16:45 |
| Wizzup | BlagovestPetrov4: what is? | 16:46 |
| uvos__ | h-d/h-home dont survie the resolution changing | 16:46 |
| Wizzup | BlagovestPetrov4: https://wizzup.org/example.png | 16:47 |
| uvos__ | you have to also kill it when pluging in the lapdock | 16:47 |
| Wizzup | and if you do that 10 times it will restart the device | 16:47 |
| Wizzup | :P | 16:47 |
| uvos__ | depends on how it exits i hope | 16:47 |
| uvos__ | or is dsme so broken it reboots even if h-d exits sucess | 16:47 |
| BlagovestPetrov4 | understood :) | 16:48 |
| uvos__ | really tho | 16:48 |
| uvos__ | switching to lxde or so works mutch better (on a montior + keyboard) | 16:49 |
| uvos__ | currently only possible via reboot | 16:49 |
| BlagovestPetrov4 | idea for dirty fix: Using a special exit code from Hildon | 16:49 |
| uvos__ | for what? | 16:50 |
| BlagovestPetrov4 | for restarting Hildon | 16:50 |
| BlagovestPetrov4 | but switching to another desktop is also a good idea | 16:50 |
| Wizzup | here's an idea: fix hildon so that it just deals with res changes | 16:50 |
| Wizzup | :D | 16:50 |
| BlagovestPetrov4 | :D | 16:50 |
| Wizzup | freemangordon: this is not a great example but here's the worldclock bg: https://wizzup.org/worldclock-hd.png vs https://wizzup.org/worldclock-reg.png | 16:54 |
| Wizzup | you can see the grainy parts | 16:54 |
| Wizzup | this is everywhere in every there on any device with res > 800x480 | 16:54 |
| Wizzup | it's in the title bars, etc | 16:54 |
| uvos__ | but this is just issues with the images being 16bit no | 16:55 |
| uvos__ | are you switching to 32ẞ | 16:55 |
| uvos__ | ? | 16:55 |
| uvos__ | with the upscaleing | 16:55 |
| Wizzup | $ file ./beta/backgrounds/clock.png | 16:56 |
| Wizzup | ./beta/backgrounds/clock.png: PNG image data, 800 x 424, 8-bit/color RGB, non-interlaced | 16:56 |
| Wizzup | $ file ./beta/backgrounds/clock.png | 16:56 |
| Wizzup | ./beta/backgrounds/clock.png: PNG image data, 3200 x 1696, 8-bit/color RGB, non-interlaced | 16:56 |
| Wizzup | I don't know what you mean | 16:56 |
| Wizzup | the problem is that the n900 themes were basically made 'pixel perfect' | 16:57 |
| Wizzup | so any upscaling, or any of it, will become grainy, especially the gradients (which is most) | 16:57 |
| uvos__ | hmm ok, all the theme images look 16bit and since the n900 ran in 16bit i assumed they where encoded 16bit too | 16:57 |
| Wizzup | don't think so | 16:57 |
| uvos__ | even looking at the images pixel perfect theres still excessive banding | 16:57 |
| Wizzup | in an image viewer you mean I guess? | 16:57 |
| uvos__ | yeah | 16:57 |
| Wizzup | doing this for the lockslider would be good too I imagine :p | 16:59 |
| uvos__ | lockslider is particually broken | 16:59 |
| uvos__ | since the slider part is part of the image | 16:59 |
| uvos__ | theres no way that will ever line up right on dfiferent size/aspect displays | 16:59 |
| uvos__ | really that just needs replaceing | 17:00 |
| Wizzup | would still be nice if it wasn't grainy meanwhile | 17:00 |
| uvos__ | sure | 17:00 |
| Wizzup | BlagovestPetrov4: if you get a bit higher res photo of this I can put it on twitter | 17:29 |
| BlagovestPetrov4 | sure, I'll try | 17:40 |
| BlagovestPetrov4 | the light is not good enough in the lab | 17:40 |
| BlagovestPetrov4 | there is an event and the people are coming. Later at home :) | 17:41 |
| Wizzup | :) | 17:42 |
| Wizzup | ok, I have realesrgan-ncnn-vulkan running locally, so I can upscale on my laptop (semi) automatically | 18:03 |
| freemangordon | Wizzup: rescaling background was easy | 18:25 |
| freemangordon | correctly positioning the buttons - still not ready | 18:25 |
| freemangordon | will take some time | 18:25 |
| Wizzup | freemangordon: I have the same problem with clock-ui :) | 19:12 |
| Wizzup | freemangordon: uvos: if I make some "hd" theme, shall I create a new package for it, or a new version of the same package? | 19:37 |
| Wizzup | i.e. do I make hildon-theme-beta-hd or just a new hildon-theme-beta release | 19:37 |
| Wizzup | freemangordon: I think the themes (alpha, beta, devel) can maybe go with rafael2k_'s ringtones change | 20:08 |
| Wizzup | whereever we end up placing it | 20:09 |
| rafael2k | yay! | 22:12 |
| freemangordon | Wizzup: why do we need both normal and h-d package? | 22:13 |
| freemangordon | I think having only one should be ok | 22:14 |
| uvos | h-d xD | 22:27 |
| uvos | hd | 22:27 |
| uvos | and yes 1 should be plenty | 22:28 |
| Wizzup | freemangordon: ok, agreed | 22:30 |
| Wizzup | hahaha well just upscaling every image didn't work ;) | 22:35 |
| freemangordon | wait, you want to upscale everything? | 22:37 |
| freemangordon | not only backgrounds? | 22:37 |
| Wizzup | I was just toying around | 22:39 |
| norayr | droid4 extended life battery is $89 on amazon. i remember there was a cheaper (~$25) link. | 22:45 |
| norayr | my battery really sucks. :/ | 22:45 |
| Wizzup | got a link? | 22:49 |
| norayr | minute | 23:21 |
| norayr | https://www.amazon.com/Mugen-Power-Extended-Battery-Motorola/dp/B00GQDVXYM/ref=sr_1_7?crid=3LK632TJCA6TB&keywords=motorola+droid+4+battery&qid=1671140648&sprefix=motorola+droid4+batter%2Caps%2C255&sr=8-7&ufe=app_do%3Aamzn1.fos.006c50ae-5d4c-4777-9bc0-4513d670b6bc | 23:21 |
| buZz | quite sure thats fake | 23:23 |
| buZz | well, maybe not :P | 23:23 |
| uvos | those are real | 23:29 |
| uvos | but they are really old | 23:29 |
| uvos | dont buy it | 23:29 |
| norayr | uvos, what do you do? soldev wires to other battery? and then connect the wires with screws to d4? | 23:39 |
| norayr | isn't it dangerous to touch battery with hot things like soldering iron? | 23:39 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
