| Josh_2 | Hi, I have plugged in a new external monitor and the text is all slighly blurry | 08:31 |
|---|---|---|
| Josh_2 | I am pretty sure i have had this issue before but in specific applications like Firefox, now all the text on this external monitor is slighly off | 08:32 |
| Josh_2 | However if I'm directly in a tty there is no issue | 08:33 |
| gnarface | Josh_2: first thing to do is make sure the xorg log shows it having your DPI detected correctly | 08:46 |
| gnarface | you can use xrandr to make sure it's using the optimal refresh and resolution | 08:47 |
| gnarface | after that if you still don't like how it looks, run: dpkg-reconfigure fontconfig-config | 08:47 |
| gnarface | then: dpkg-reconfigure fontconfig | 08:47 |
| gnarface | (not sure if the second one matters if you're not adding fonts) | 08:47 |
| gnarface | you might have to restart xorg to have fontconfig changes fully propagate but some programs will show the changes immediately | 08:48 |
| gnarface | window managers may have their own dpi settings | 08:50 |
| gnarface | you have to make sure it all matches the manual spec for the display | 08:50 |
| gnarface | if you want it perfect | 08:50 |
| Josh_2 | I just tried to find the dpi for the display, but it doesn't appear to be listed in the specs | 08:50 |
| Josh_2 | https://storage-asset.msi.com/datasheet/monitor/global/Optix-G24C4.pdf | 08:50 |
| gnarface | you'll have to do math | 08:50 |
| gnarface | DPI is just dots-per-inch | 08:51 |
| gnarface | if the physical display area size (not model size) is not listed in there you'll have to get out a tape measure sorry | 08:51 |
| gnarface | the xorg log should list whatever it auto-detected, it should be right usually these days and if it's wrong it'll be obviously wrong by a lot | 08:52 |
| gnarface | i think the new xorg versions are capable of supporting different horizontal and vertial resolutions but the pixels are usually square | 08:53 |
| gnarface | *different horizontal and vertical dpi i mean | 08:53 |
| Josh_2 | Within Xorg.0.log I can see one entry for 'dpi' and it says "DPI set to (143, 144)" | 08:53 |
| Josh_2 | I calculated by DPI, its 93 or so | 08:54 |
| gnarface | hmm, interesting, are you sure? | 08:54 |
| gnarface | verified roughly by physical measurement? | 08:55 |
| gnarface | 93 is a completely typical DPI but it'd be weird for it to be auto-detected wrong in that direction | 08:55 |
| Josh_2 | Yes, I used an online calculator with the size directly from the spec | 08:55 |
| gnarface | i'd say try adding it to a xorg.conf snippet, you don't need the whole config anymore, you can just have the stanza that sets the DPI | 08:56 |
| gnarface | it'll be either obviously better or obviously worse | 08:56 |
| Josh_2 | https://imgur.com/MLtEhyv.png I scaled the monitor by 1.5 using xrandr and now you can really see the problem | 09:03 |
| Josh_2 | gnarface: I gave up, just unplugged that monitor and I'm using mine instead | 09:56 |
| dokma | I'm having problems getting my server to boot for 3 days now. I'm getting dropped into initramfs prompt that is not accepting keyboard input whereas grub menu does accept keyboard input just a few seconds prior. | 11:19 |
| dokma | initramfs is failing to mount /dev/md0 - no such device | 11:19 |
| dokma | even though just a few lines prior it prints that e2fsck has check the very same /dev/md0 | 11:19 |
| dokma | What could possibly cause initramfs prompt to not accept keyboard input? | 11:20 |
| Walex2 | dokma: some weird USB incompatibility perhaps. | 11:27 |
| rrq | perhaps adding "init=/bin/sh" to the boot line would bring you to a command prompt within initramfs, and there you can run mdadm and fsck etc to get your raid checked and fixed | 11:27 |
| Walex2 | dokma: sometimes it is USB1/2/3 hub issues. | 11:27 |
| Walex2 | dokma: if you are accessing the server remotely via a KVM: there are trillions of subtle KVM compatibility issues. USB is compatibility hell beyond the trivial cases. | 11:28 |
| Walex2 | dokma: for example the combination mechanical/gamer keyboard and KVM is usually full of problems. | 11:29 |
| dokma | rrq: raid is fine | 11:36 |
| dokma | I can assemble it from rescue | 11:36 |
| dokma | Walex2: I am accessing via KVM | 11:37 |
| dokma | However the keyboard input works in the grub menu, and then a few seconds later in the initramfs console it does not | 11:37 |
| dokma | Will try init=/bin/sh to see if I can get a working prompt | 11:42 |
| jemadux | i use at the moment debian ... i am thinking to migrate to devuan ... if i repent my choice can I mirgrate back to debian ? | 12:19 |
| dokma | rrq, Walex2 darn initramfs failed to assemble my raid1 array. I had to put a script into init-premount to enable the raid array myself | 12:48 |
| dokma | how silly is that? | 12:48 |
| dokma | jemadux: hating systemd or? | 12:49 |
| jemadux | dokma: i do not even care ... | 12:49 |
| jemadux | for me it's same | 12:49 |
| dokma | From what I recollect from my migration to Devuan all of the steps should be reversible but I would not guarantee it | 12:50 |
| Walex2 | jemadux: Devuan and Debian are essentially the same thing except for "init freedom" :-) | 13:12 |
| Walex2 | jemadux: "migrating" between the two is fundamentally a no-op except for 'init' related packages. | 13:12 |
| fsmithred | migrations can sometimes be messy. | 13:13 |
| buZz | debian is just ubuntu with less ugly preset themes | 13:13 |
| buZz | devuan is debian with less redhat software | 13:13 |
| fsmithred | I would not discount the ugliness of default debian themes. | 13:14 |
| Walex2 | buZz: I often say that Debian is an Ubuntu fork nowadays, just like Devuan :-) As so many Debian/Devuan DDs work for canonical. | 13:14 |
| buZz | Walex2: lol sure | 13:14 |
| buZz | canonical couldnt start to make a hannahmontanalinux if their lives depended on it | 13:14 |
| Walex2 | dokma: the GRUB kernel and Linux kernel use different methods to access USB peripherals like kbd and mouse... | 13:15 |
| fsmithred | jemadux, maybe try a fresh install on some spare hard drive space or even on a usb stick first. | 13:15 |
| fsmithred | if you don't normally do stuff with the init system, you might not notice any difference | 13:16 |
| jemadux | I remember when I used Artix | 13:17 |
| gast0n | o/ | 17:00 |
| gast0n | What do these 5GB ISOs contain? devuan_chimaera_4.1_0_amd64_pool1.iso | 17:01 |
| ananimusus | dkms fails to build this ( https://github.com/loimu/rtbth-dkms ) kernel module. DKMS build log: https://paste.debian.net/1231129 | 17:04 |
| bb|hcb | gast0n: The most popular packages for offline installs | 18:35 |
| gast0n | Thanks 👍 | 18:35 |
| bb|hcb | ananimusus: I have just tried, on chimaera it builds fine; most probably you are missing part of the build system, e.g. apt install build-essential | 18:41 |
| bb|hcb | Also maybe apt install linux-headers-amd64 | 18:42 |
| ananimusus | This package are already installed | 18:45 |
| ananimusus | *packages | 18:45 |
| bb|hcb | ananimusus: the problematic stdarg.h header is a c++ thing; I think that you can safely comment that line (e.g. like: //#include <stdarg.h>) | 18:48 |
| bb|hcb | ananimusus: BTW. I tested it on chimaera with kernel 5.10.0-10-amd64, I see your kernel is newer... | 18:50 |
| ananimusus | I fixed the first error by simply copying the required file from the Linux kernel repository, and I have the stdarg.h file at /usr/include/c++/11/tr1/stdarg.h . How do I get dkms to find it? | 19:02 |
| ananimusus | Simple copying works here too! But if you had these files initially without any problems, can you see what packages they were delivered with? | 19:14 |
| bb|hcb | That is c++ stuff, linux kernel is c only, should not be related. That is why I suggested to comment that include | 19:18 |
| * used____ wonders of systemd is not coded in C++ and sneaked into the kernel | 19:27 | |
| syco | rust! | 19:34 |
| syco | rust++ | 19:34 |
| ananimusus | The module seems to be assembled, but life would be boring if there were no third layer in this puzzle. `sudo bluetoothctl power on` returns `Failed to set power on: org.bluez.Error.Busy` | 19:54 |
| used____ | ananimusus: find out what else uses the device. rfkill ? | 19:57 |
| ananimusus | How to check what else can use the device? Also, I don't use rfkill. | 20:19 |
| ananimusus | I find line that tells `bluetoothd[19710]: profiles/sap/server.c:sap_server_register() Sap driver initialization failed` in syslog | 21:56 |
| ananimusus | And the next: `bluetoothd[19710]: sap-server: Operation not permitted (1)` | 21:58 |
| ananimusus | I disable SAP plugin in bluetooth service. Now: `bluetoothd[433]: Failed to set mode: Failed (0x03)`. When will this end... | 22:16 |
| rrq | ananimusus: ensure that /etc/dbus/system.d/bluetooth.conf includes <allow send_interface="org.freedesktop.DBus.ObjectManager"/> for group="bluetooth" | 22:28 |
| rrq | I'm not sure why, but it made a world of difference for me :) | 22:30 |
| ananimusus | I didn't expect to see system.d in devuan. And this line exists. | 22:44 |
| golinux | ana | 22:52 |
| golinux | ananimusus: Please have a look at this https://dev1galaxy.org/viewtopic.php?id=1925 | 22:53 |
| golinux | Explains why you see those files that do nothing but take up space. IOW it is a cosmetic issue that isn't worth the effort to clean up | 22:54 |
| brocashelm | is this one of the top five faqs of devuan? | 22:57 |
| xrogaan | system.d isn't systemd. | 23:26 |
| xrogaan | if you look into /etc/dbus-1/, you'll see session.d and system.d. Those '.d' are more likely there as a references for daemon. | 23:27 |
| xrogaan | Actually, I'm not quite sure why we use the .d affix | 23:27 |
| fluffywolf | .directory.... | 23:27 |
| xrogaan | could as well be .f for folder. | 23:28 |
| xrogaan | but yeah, the dbus stuff is badly named. | 23:28 |
| xrogaan | fluffywolf: you are right. It stands for directory. | 23:30 |
| golinux | brocashelm: It is pinned at the top of the Devuan forum. | 23:36 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
