Fix filter string behaviour to be more intuitive before lots of people start depending on it

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



SSIA

The current "grandfathered" filter format behaves counter-intuitively.
Let me describe it based on my experiments:
     1. there is a "hard default" that disables all devices (aka
        -1,-1,-1,-1,0), it must be always overwritten if you wish to
        auto-share anything. This is not advertised anywhere
     2. there is a "soft default" that enables everything but HID
        devices (aka 3,-1,-1,-1,0|-1,-1,-1,-1,1)
     3. when user specifies a custom filter string, it
              * replaces string from #2
              * is based on top of #1

All combined together cause unexpected behaviours like the one described
in https://bugzilla.redhat.com/show_bug.cgi?id=823541 .

The most straightforward fix seems to get rid of "soft default" #2 and
use its value in "hard default" #1. That way, when user specifies
--spice-usbredir-filter="11,-1,-1,-1,0", the effective filter string
will be what user will expect:
"3,-1,-1,-1,0|11,-1,-1,-1,0|-1,-1,-1,-1,1"

instead of current behaviour where such string will become
"11,-1,-1,-1,0|-1,-1,-1,-1,0", effectively block-all "-1,-1,-1,-1,0"

Hans, do you think this is doable in a short time frame? If it is not
done this way soon, people will constantly ask about that...

David

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]