> Are you saying we re-enable lines:
> ENV{PRODUCT}=="10c4/ea60
I didn't talk about these lines, but the 403/6001 ones, that do match a
proper Braille manufacturer string:
ENV{PRODUCT}=="403/6001/*", ATTR{manufacturer}=="Hedo Reha Technik GmbH",
ENV{BRLTTY_BRAILLE_DRIVER}="hd", GOTO="brltty_u
> Perhaps something like 1A86/7523 plugged on 1A40/0101. That being said
it seems like both are generic ids
Ah, but this 1A86/7523 line is properly emitted by upstream in the `usb-
generic.rules` file, so it shouldn't be enabled by default, to avoid
matching such combination of generic devices.
T
> aren't the identifiers in ENV{PRODUCT} already idVendor/idProduct?
I don't know the details. From what I gather from the upstream source
code, this device has a special rule to appear like this in the udev
file:
Drivers/Braille/Baum/braille.c:
{ /* NLS eReader Zoomax (20 cells) */
.v
> if there is an active IPv6 regular (non-loopback) interface with an
IPv6 address and network connection, then connection attempts to ::1
seem to hang and timeout
Probably it uses the default route to send packets to ::1, which is
deemed not to receive any response.
> I haven't seen any other da
Ok, I better understand why this has never shown up in most situations.
> my system has functional IPV4 and IPV6
Well, it still behaves oddly on the ip6-localhost case:
> connect(3, {sa_family=AF_INET6, sin6_port=htons(4101),
sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr),
sin6_
This is very surprising: what xbrlapi tries to connect to by default is
a local socket in /var/lib/BrlAPI/0 so that should be completely
independent from TCP/IP networking configuration, and should be either
succeeding or failing immediately.
Just to be sure: Does /var/lib/BrlAPI/0 exist? Is brltt
Concerning 1a86:7523, the udev rules file in ubuntu indeed seems to be
missing the manufacturer filter:
debian/brltty.udev.rules says:
ENV{PRODUCT}=="1a86/7523/*", ENV{BRLTTY_BRAILLE_DRIVER}="bm",
GOTO="brltty_usb_run"
while it should be:
ENV{PRODUCT}=="1a86/7523/*", ATTRS{idVendor}=="1a40", ATT
Hello,
beattie, le mar. 20 sept. 2022 15:21:36 -, a ecrit:
> can't find anything in the udev,
That's be in ./lib/udev/rules.d/85-brltty.rules, this line:
ENV{PRODUCT}=="1a86/7523/*", ENV{BRLTTY_BRAILLE_DRIVER}="bm",
GOTO="brltty_usb_run"
> I think somebody did not do their testing.
Not man
The simple workaround is to remove the package, or remove the entry from
the udev file.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to brltty in Ubuntu.
https://bugs.launchpad.net/bugs/1990189
Title:
brlttty claiming CH341 usbtty devi
Ok. That'd be tricky to filter. Fortunately with brltty 6.5 such generic
entries are kept apart so that they can be packaged separately.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to brltty in Ubuntu.
https://bugs.launchpad.net/bugs/199
Hello,
beattie, le lun. 19 sept. 2022 19:07:54 -, a ecrit:
> [139099.370766] usb 1-2.1.2: New USB device found, idVendor=1a86,
> idProduct=7523, bcdDevice= 2.63
Could you run
lsusb -v
so we get more information on how the generic bridge announces itself?
Samuel
--
You received this bug
> it's a bit unclear to me which entries there should be considered
'generic USB IDs'?
They are marked "Generic Identifier", that's
0403:6001
10C4:EA60
10C4:EA80
> I also don't understand why those rules are debian specific
See the diff between ./debian/brltty-udeb.udev.rules and
./Autostart/Ud
orca only suggests brltty, it's the *-desktop packages which seem to be
recommending brltty.
If Ubuntu really wants to install brltty by default, it should disable
the udev entries for the generic USB IDs
--
You received this bug notification because you are a member of Desktop
Packages, which i
Yes, unfortunately there is no way to fix it in that case. The udev
rules properly avoid starting brltty when the iManufacturer field is
changed from FTDI to the actual manufacturer of the device, but not when
it is left to FTDI.
--
You received this bug notification because you are a member of D
> In this case, brltty appeared (or at least the device claim) after a
dist-upgrade
Ah, do you happen to have a log of that dist-upgrade, so we can
determine what brought it in?
> It still feels very bad form for a vendor device to use the default
VID/PID of the underlying converter chip
Yes. Un
Debian is installing the brltty package only when brltty was used during
installation.
Brltty gets started during installation either through the udev rules,
or started manually from the kernel command line. The finish-install
script just checks out /var/run/brltty.pid to determine whether a brltt
Yes, but it is meant to be so: the Seika Braille device is announced as
such, so we have to recognize such devices in brltty, otherwise the
Seika Braille devices would not work at all.
The question is rather: why is brltty installed on your system? It is
supposed to be installed only if you instal
Ah, the patch is already in brltty 6.4 actually, so no change on the
Debian side actually :)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to brltty in Ubuntu.
https://bugs.launchpad.net/bugs/1950488
Title:
brltty ftbfs in jammy
Status
Ok, thanks!
The corresponding commit upstream is
e6ed2372887ac0106db8854f70e9b2fdcadec74f, attached here, could somebody
check that this fixes the build issue on Ubuntu? I'll then integrate the
patch in Debian as well.
** Attachment added: "patch"
https://bugs.launchpad.net/ubuntu/+source/brl
> it is probably newer python versions being stricter with the use of
non existing options?
The --without-viavoice is not passed to the python bindings, so that
cannot be the problem.
That said I have now dropped the option from debian/rules, thanks :)
--
You received this bug notification beca
Please provide the whole build log.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to brltty in Ubuntu.
https://bugs.launchpad.net/bugs/1950488
Title:
brltty ftbfs in jammy
Status in brltty package in Ubuntu:
Confirmed
Bug descriptio
It seems I have to insist again: patch
https://launchpadlibrarian.net/405256420/patch should definitely really
really be applied. As explained in
https://bugs.launchpad.net/ubuntu/+source/gnome-
shell/+bug/1508146/comments/73 that script should really *not* pass
--force to setupcon. There is no rea
I guess this is due to the following change in at-spi2-atk:
* Meson: don't hard-code shared_library (!19).
which made meson emit a lot of new libraries in Requires.private of atk-
bridge-2.0.pc, and thus the -dev package now has to add them in Depends.
--
You received this bug notification beca
But scripts changing between scancode and ascii/unicode (such as for
some terminal emulation, dosbox, etc.) would break. I'm not saying they
are widespread, but I have seen this kind of use, and requiring such
flag will suddenly break them.
--
You received this bug notification because you are a
How will kbd_mode know whether it's safe or not?
Adding a -f option to kbd_mode will at best break some *other* existing
scripts, while this very script should really definitely *NOT* pass -f
to setupcon. That is the nonsense which needs to be fixed.
--
You received this bug notification because
That is when updating the console-setup package, yes. As mentioned on
https://bugs.launchpad.net/ubuntu/+source/gnome-
shell/+bug/1508146/comments/73 that's because its config script passes
--force to setupcon, it really shouldn't, as mentioned there
--
You received this bug notification because
Xorg can't do anything about intercepting Alt-key, it's the kernel which
takes the shortcut away.
Again, as mentioned on https://bugs.launchpad.net/ubuntu/+source
/console-setup/+bug/520546/comments/66
«
proposed fix:
https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/520546/+attac
*** This bug is a duplicate of bug 520546 ***
https://bugs.launchpad.net/bugs/520546
Is there really any reason why keyboard-configuration.postinst passes
--force to setupcon?
In Debian we do this in the Debian installer because it is running
within a bterm and thus can't detect it's running
Charlie: do you have the espeak package installed? It is needed to have
espeak-generic working
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to speech-dispatcher in Ubuntu.
https://bugs.launchpad.net/bugs/571956
Title:
sd_generic breaks
>From the upstream policykit bug entry, it is actually a misuse of the
policykit API from brltty. I have uploaded a fix in Debian's brltty
5.6-5.
Ubuntu should definitely include the policykit-fix patch contained in
that 5.6-5 version as an update to ubuntu 18.04, otherwise all blind
users will ha
Yes, disabling that patch fixes the issue.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-1 in Ubuntu.
https://bugs.launchpad.net/bugs/1782320
Title:
Braille display inoperable in GUI since polkit-update
Status in policykit
This is most probably due to the introduction of Fix-CVE-2018-1116
-Trusting-client-supplied-UID.patch
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-1 in Ubuntu.
https://bugs.launchpad.net/bugs/1782320
Title:
Braille displa
I can confirm the same issue on Debian: upgrading from version 0.105-20
to version 0.105-21 brings the same issue.
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-1116
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pol
Note: to reproduce the issue, one just needs to install an Ubuntu 18.04
system, start brltty by hand as root with:
sudo brltty -b no
then try to connect to it as normal logged-in user through brlapi:
python3
>>> import brlapi
>>> b = brlapi.Connection()
which shouldn't raise an exceptio
This seems to be an issue within policykit itself. Printing the actual
error shows:
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: process with PID
12570 has been replaced
>From reading the source code, it seems that policykit is checking the
start time of the program and finds a mismatch.
Well, this is not a real solution, we need to fix polkit, otherwise all
users will have the same issue, and we don't want to make them all
revert back to file-based authentication.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to brltty in
lasakro, stu: which USB ID does your device have?
(otherwise we can't know what to fix in brltty)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to brltty in Ubuntu.
https://bugs.launchpad.net/bugs/874181
Title:
brltty daemon prevents cr
I don't know how ubuntu manages that.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to brltty in Ubuntu.
https://bugs.launchpad.net/bugs/1741070
Title:
Please merge brltty (main) 5.5-4 from Debian unstable (main)
Status in brltty packa
I have pushed the AT_SPI_BUS removal patch to branch
https://code.launchpad.net/~samuel-thibault/lightdm-gtk-greeter/at-spi-
bus
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity-greeter in Ubuntu.
https://bugs.launchpad.net/bugs
Hello,
Still now news on this and #1366534 ? This is really hurting users...
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity-greeter in Ubuntu.
https://bugs.launchpad.net/bugs/1670933
Title:
[PATCH] Accessibility partly broken d
Hello,
Just to confirm that the approch proposed by Luke is sound. Removing the
AT_SPI_BUS property would really be the safest for the user session:
even if systemd doesn't manage to properly clean the at-spi dbus, at
least the session isn't exposed to its existence.
--
You received this bug not
Hello,
This was reported in debian http://bugs.debian.org/851623 , and that led
to upstream fix
https://github.com/brltty/brltty/commit/0a5341121ba8f4de24407ce2a4d5369dadf5d099
** Bug watch added: Debian Bug tracker #851623
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851623
--
You recei
I have suggested a patch to Dave, upstream maintainer of brltty
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to brltty in Ubuntu.
https://bugs.launchpad.net/bugs/1579531
Title:
openConnection: connect: No such file or directory
Status
I've commited it, thanks!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to brltty in Ubuntu.
https://bugs.launchpad.net/bugs/1567658
Title:
ubuntuBSD support
Status in brltty package in Ubuntu:
New
Bug description:
Hi
Please co
Hello,
While I could reproduce the issue with java-atk-wrapper 0.30, I can not
reproduce it with java-atk-wrapper 0.33. I had reported the issue on
https://bugzilla.gnome.org/show_bug.cgi?id=698095 , and it was reported
as fixed.
Perhaps it is the time to consider re-enabling accessibility in
/et
Well, yes, brltty needs mountkernfs, like a lot of software actually.
Having it disabled seems the culprit here, not brltty.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to brltty in Ubuntu.
https://bugs.launchpad.net/bugs/1365054
Title:
I too believe that Andreas' proposal is the right one. It permits people
who really want the extra 5th level to be able to easily get it, while
not breaking the 99% usual usage.
Just for the record, I had not seen the linuxfr discussion. I guess
mostly only people who would want the extra 5th leve
I too believe that Andreas' proposal is the right one. It permits people
who really want the extra 5th level to be able to easily get it, while
not breaking the 99% usual usage.
Just for the record, I had not seen the linuxfr discussion. I guess
mostly only people who would want the extra 5th leve
Hello,
Until a solution is to be found, could 518c769d be reverted for now?
Breaking the very standard behavior of right control in all applications
(e.g. xterminals!!) is really not acceptable, compared to the few issues
that the behavior has without it.
Samuel
--
You received this bug notific
Hello,
Until a solution is to be found, could 518c769d be reverted for now?
Breaking the very standard behavior of right control in all applications
(e.g. xterminals!!) is really not acceptable, compared to the few issues
that the behavior has without it.
Samuel
--
You received this bug notific
This should get fixed by the next brltty version, 4.5, to be released
very soon.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to brltty in Ubuntu.
https://bugs.launchpad.net/bugs/1082679
Title:
brlapi.OperationError.__str__ return byte
Attila Hammer, le Mon 14 Jan 2013 07:22:17 -, a écrit :
> In Ubuntu Quantal and Ubuntu Raring if I enabling Orca with braille support,
> the Orca's debug.out file I see following traceback error message:
> BrlTTY seems to have disappeared:
>
> Traceback (most recent call last):
> File "/usr
52 matches
Mail list logo
