[qubes-users] system-config-printer gives different results in template and VM

2021-01-19 Thread Franz
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.


Re: [qubes-users] Re: High dom0 CPU usage by qubesd

2021-01-19 Thread Vít Šesták
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

2021-01-19 Thread 'qtpie' via qubes-users
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.


Re: [qubes-users] issues with i3, xrandr and keyboard

2021-01-19 Thread Jarrah


> 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

2021-01-19 Thread pillule



'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

2021-01-19 Thread pillule



'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] system-config-printer gives different results in template and VM

2021-01-19 Thread unman
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.