Re: [qubes-users] system-config-printer gives different results in template and VM
On Tue, Jan 19, 2021 at 11:25:47AM -0300, Franz wrote: > Hello, > > if I write system-config-printer in the debian template I get the expected > GUI to config the printer and everything works as expected. > > If I write the same in the VM depending from the template, I get: > Printing service not available. Start the service on this computer or > connect to another server. > If I click on start the service, nothing happens. > > After many years using Qubes, the template and the VM depending from the > template always behaved in the same way. I cannot understand why the > template works and the VM does not. > > To be sure, I tried on two different VMs depending from the same template > an none works > Best > Franz > You don't have cups/cupsd enabled in the qube: enable it on Services tab of GUI or using `qvm-service` -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20210120022029.GD30298%40thirdeyesecurity.org.
Re: [qubes-users] issues with i3, xrandr and keyboard
> For the qubes way to change the vm keymaps, idk sorry. I only know it > does > not allow to change your keyboard options so I looked away. For me at least, changing the xfce setting carries through to i3. This also propagates to VMs, but only once on VM start. Repeated propagation is slated for r4.1. Alternatively, VM keyboards can be changed from Qube Manager (right click, set keyboard layout) when VMs are powered on. This should persist, but is specific to one VM. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1d45ddad-1496-77c6-19ba-23127ba7d0d0%40undef.tools.
Re: [qubes-users] issues with i3, xrandr and keyboard
'qtpie' via qubes-users writes: Also, how do you change your keyboard settings under i3/Fedora/Qubes? I want to use the us-altgr-intl keymap. Under i3 when I do $ localectl set-keymap us-altgr-intl in a qube vm terminal, this has no effect in applications. The right alt key instead remains used to open menu's (altgr+f for File, altgr+e for Edit, etc.) If I could use altgr-intl and retain that functionality that would actually be great. Do you mean it activates the toolbar in a software such as firefox (Alt_R keysym) or it activates a contextual menu in a soft such as gnome-terminal (Menu keysym) ? I think such things may be configurable in the application itself. The thing is when you use AltGr as right Alt, you are now sending ISO_Level3_Shift as keysym to the application instead of Alt_R, so the application must be aware you want also use it for your things. A trick, if you do no want to configure the applications, may be to use an utility such as xcape (in dom0) to send Alt_R when you press and release the key alone, and ISO_Level3_Shift when you press the key in conjonction of another. I hope that help. -- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/87im7sh8e6.fsf%40host.localdomain.
Re: [qubes-users] issues with i3, xrandr and keyboard
'qtpie' via qubes-users writes: - Does anyone have a comparable setup and what xrandr command do you use? - Is there an alternative to using xrandr under i3? Do you have tried to use an utility such as lxrandr or arandr to generate the command of xrandr for you ? Also, how do you change your keyboard settings under i3/Fedora/Qubes? I want to use the us-altgr-intl keymap. Under i3 when I do $ localectl set-keymap us-altgr-intl in a qube vm terminal, this has no effect in applications. The right alt key instead remains used to open menu's (altgr+f for File, altgr+e for Edit, etc.) If I could use altgr-intl and retain that functionality that would actually be great. localectl is an utility correlated to systemd, its changes only takes effect *after* a reboot and must be applied in the templateVM. To change your keymap on the fly you should use setxkbmap. Its changes only last the session. ‘setxkbmap -layout us -variant altgr-intl’ I have bugs with localectl. (options will not clean) Instead I export my own keymap with xkbcomp and loads it in session scripts. For the qubes way to change the vm keymaps, idk sorry. I only know it does not allow to change your keyboard options so I looked away. -- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/87k0s8h95f.fsf%40host.localdomain.
Re: [qubes-users] Re: High dom0 CPU usage by qubesd
Although my implementation is not fully complete, I have decided to share my progress: https://github.com/v6ak/qubes-i3status-dir It is available under a WTFPL-like license. Regards, Vít Šesták 'v6ak' On Monday, January 18, 2021 at 2:39:09 PM UTC+1 Vít Šesták wrote: > BTW, I've started the reimplementation of qubes-i3status as a Python > wrapper around i3status. I am trying to be quite conservative – in the > default settings, there should be no visible difference except CPU load, > periodic freezes and bug fixes (battery status). > > * Some indicators (battery, load and time) are already present, they just > need some adjustments of the format in order to be a drop-in replacement. > * Disk status was easy to implement. I just need to verify that it can > properly handle the change of default pool. > * Running qubes: I need to study the events deeper… > * NetVM status – currently, it is disabled and discouraged. I might decide > to reimplement this, but I am not 100% sure right now. > > Regards, > Vít Šesták 'v6ak' > > On Friday, January 15, 2021 at 5:40:38 PM UTC+1 David Hobach wrote: > >> Hi Vit, >> >> > * I have many VMs in my computer. >> > * I use i3 with qubes-i3status >> > * The script qubes-i3status calls command qvm-ls --no-spinner >> --raw-data >> > --fields NAME,FLAGS quite frequently. >> > * The command qvm-ls --no-spinner --raw-data --fields NAME,FLAGS seems >> to >> > cause high CPU load. Unfortunately, the process that shows the high CPU >> > usage is qubesd, not qvm-ls. >> > >> > What can be improved: >> > >> > a. Don't use qubes-i3status. Problem solved. >> > b. Optimize qvm-ls. Not sure how hard it is. >> >> This issue is really old (back from at least 3.2) and caused by each >> qvm-ls line relating to one request to qubesd. Actually it was even worse >> with 3.2. >> >> It should improve with 4.1 though, see [1]. >> >> [1] https://github.com/QubesOS/qubes-issues/issues/3293 >> >> > c. Optimize qubes-i3status. I am not sure about the ideal way of doing >> > that, but clearly running qvm-ls --no-spinner --raw-data --fields >> > NAME,FLAGS just to compute the number of running qubes is far from >> optimal. >> > One could add --running. And maybe it could have been written without >> > flags. The script just ignores VMs with the first flag being “0” (maybe >> in >> > order to ignore dom0) and the second flag being “r” (probably not >> needed >> > with --running). >> >> Filtering might work in the meantime, yes. >> >> BR >> David >> >> -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b98004f9-01be-447c-9388-65944f948a14n%40googlegroups.com.
[qubes-users] issues with i3, xrandr and keyboard
Hi, A few questions about using Qubes with i3. I think the idea behind i3 is great, but getting everything to work is a bit of a struggle. I'm using the i3 window manager with Qubes in a multi-monitor setup. The laptop monitor is 1920x1080, the external monitor is 2560x1440. To enable the second monitor I do $ xrandr --output eDP1 --auto --right-of DP1 --output DP1 --auto. The issue I keep running in to is that about half of the time, my mouse will not work on the the external monitor on the rightmost quarter and lowest quarter (approximately). The pointer will move there, but clicks are not registered. It is as if the mousedriver sees the second monitor as 1920x1080 instead of its actual resolution. The status bar is displayed on both monitors. I have read much of what there is to read on xrandr and tried many options, like switching monitor postitions, scaling, panning, positioning, but to to avail, the issue keeps returning. I have tried comparing the output of $ xrandr -q, but there is no difference between working and error situations. - Does anyone have a comparable setup and what xrandr command do you use? - Is there an alternative to using xrandr under i3? Also, how do you change your keyboard settings under i3/Fedora/Qubes? I want to use the us-altgr-intl keymap. Under i3 when I do $ localectl set-keymap us-altgr-intl in a qube vm terminal, this has no effect in applications. The right alt key instead remains used to open menu's (altgr+f for File, altgr+e for Edit, etc.) If I could use altgr-intl and retain that functionality that would actually be great. thanks! qtpie -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8705a851-50ff-3cb2-bc2f-bf53d07ef7a2%40disroot.org.
[qubes-users] system-config-printer gives different results in template and VM
Hello, if I write system-config-printer in the debian template I get the expected GUI to config the printer and everything works as expected. If I write the same in the VM depending from the template, I get: Printing service not available. Start the service on this computer or connect to another server. If I click on start the service, nothing happens. After many years using Qubes, the template and the VM depending from the template always behaved in the same way. I cannot understand why the template works and the VM does not. To be sure, I tried on two different VMs depending from the same template an none works Best Franz -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAPzH-qC5kp%3Dz8ze8BsVmqWTvBV-ng3%3DAcfoa0hE%3DdNP_pyS4TA%40mail.gmail.com.
