Hi all,
I'm trying to improve the brltty package in openSUSE, and I noticed that
there was a udev rules file that we aren't packaging. It looks as though
it is designed to automatically start brltty if a Braille display is
connected. Anyway, after installing it and connecting my Brailliant 40,
On Sat, 29 Aug 2015, Samuel Thibault wrote:
Isn't libatspi just this.
It's supposed to be, yes. Perhaps it has improved since when I wrote the
AtSpi2, but at the time the rationale was that the old at-spi1 libatspi
was not to be rewritten for at-spi2. I can see that there are
atspi_text_get_te
On Wed, 26 Aug 2015, Samuel Thibault wrote:
Apparently, udev rules can be made to start a systemd service with
ENV{SYSTEMD_WANTS}="brltty.service"
I'm curious whether you've tried this and, if so, if you got it to work. I
was also trying to do this for openSUSE/SLED, but I couldn't get it to
Hi,
I am trying to test the development version of brltty. When I plug in my
Brailliant 40, brltty starts up. I'm confused as to what is starting
brltty, since nothing in /usr/lib/udev/rules.d references it (I don't have
the udev rules file installed at the moment). ANyhow, brltty starts but
Hi all,
Thanks for your help, Dave.
(I don't have the udev rules file installed at the moment).
Can you check with ps to see if brltty is already running before you connect
your device?
It wasn't, but I was lying--I'd forgotten that udev rules can be installed
under /etc as well, and I'd i
On Tue, 1 Dec 2015, Mike Gorse wrote:
I have it installed. Brltty starts up, and systemctl seems to time out and
kill it. This seems to be a separate issue from the division by zero (which
might only happen if I try to install the unmodified udev rules file on a
system running systemd
Hi Dave,
The log is showing a real-world problem. For some reason, the driver is
responding to what it thinks is a VarioPro-only packet that's causing it to
believe that there are no text cells. Could you please send a new log that
captures the communication between the driver and the device? To
On Tue, 1 Dec 2015, Dave Mielke wrote:
New log attached. Note that, as far as I know, this only happens if
brltty starts immediately after the device is connected. If I later
start brltty via systemd, then it starts up and works fine.
It still shouldn't be happening. May I ask you to send yet
On Tue, 1 Dec 2015, Dave Mielke wrote:
Yes, your device, for whatever reason, is indeed sending bad data. Please apply
the attached patch (baum-1.patch) and send another log.
http://straddlethebox.org/brltty2.log
That may have helped; I don't appear to be seeing the divide error
anymore.
T
Hi Dave,
I'm sorry for not replying sooner--I've been meaning to investigate more.
That may have helped; I don't appear to be seeing the divide error
anymore.
Does it work right away when you connect it, now?
If I enable brltty via systemd, then it works correctly, with or without
the patc
On Mon, 7 Dec 2015, Dave Mielke wrote:
but it still doesn't start up correctly, but I
think that that is basically a known issue in that the udev file
isn't intended to work unmodified with systemd. Ie, the systemd
documentation indicates that the Run directive is intended for a
short-running pr
Hi all,
Finally I've taken the time to debug the issue I was having a while ago.
From Autostart/Udev/udev.rules:
...
RUN+="/bin/brltty -E -P$env{BRLTTY_PID_FILE}"
...
From the udev manpage on my system:
RUN{type}
Add a program to the list of programs to be executed after p
Hi Dave,
I've changed the subject line, since I'm no longer getting a crash.
The main problem I was having was that I wasn't setting SYSTEMD_WANTS
correctly. I have the attached patch, which gets brltty to start for me when I
connect my device.
The patch wasn't attached.
Sorry about that--I
On Thu, 7 Jan 2016, Dave Mielke wrote:
I udnerstand the patch. The problem is that we need to add to it a test so that
the rules will still work when systemd isn't being used.
I've updated the patch. See attached. It should have no effect if systemd
isn't being used.
Thanks,
-Mikediff --git
On Thu, 7 Jan 2016, Dave Mielke wrote:
Attached. Let me know if you need anything else.
Even though it's not crashing anymore, it's still receiving data that's making
it think the device has 26 cells. Please send another log with:
-ldebug,outpkts,inpkts,ingio
Yeah, that seemed strange, an
On Thu, 7 Jan 2016, Dave Mielke wrote:
This log didn't have the extra data: -ldebug,outpkts,inpkts,ingio
Ugh. Sorry. Sent you the wrong log. This should be better.
Thanks,
-Mike2016-01-07@15:40:58.369 [brltty] BRLTTY 5.3.1 rev unknown [http://brltty.com/]
2016-01-07@15:40:58.369 [brltty] lock
On Thu, 7 Jan 2016, Dave Mielke wrote:
I've committed your update, but please try replacing your PROGRAM= with
TEST="/sys/fs/cgroup/systemd" to see if it works.
It needs to be TEST==, rather than TEST=, but, yes, that works for me.
-Mike
___
This me
Hi Dave,
Please test the attached patch (b40-1.patch).
That does, in fact, fix the symptom that I was seeing--the banner now
times out, and brltty displays the correct line of text.
Thanks,
-Mike
___
This message was sent via the BRLTTY mailing li
Hi Dave,
Please test the latest commit to verify that it's correct.
Tested. Yes, that works.
Is there something we can do on remove in order to stop the service?
I asked a colleague who is more familiar with systemd than I am, and he
pointed me to this link:
http://unix.stackexchange.co
On Fri, 8 Jan 2016, Mike Gorse wrote:
Please test the latest commit to verify that it's correct.
Tested. Yes, that works.
Is there something we can do on remove in order to stop the service?
I asked a colleague who is more familiar with systemd than I am, and he
pointed me to this
On Fri, 8 Jan 2016, Mike Gorse wrote:
On Fri, 8 Jan 2016, Mike Gorse wrote:
Please test the latest commit to verify that it's correct.
Tested. Yes, that works.
Is there something we can do on remove in order to stop the service?
I asked a colleague who is more familiar with sy
e libdbus, rather than
polkit-gobject, if people would prefer that.
Thanks,
-Mike
From 1cebd3b07a2dd0c0fff43fcc721e0726a1e3c1d8 Mon Sep 17 00:00:00 2001
From: Mike Gorse
Date: Thu, 28 Jan 2016 07:54:31 -0600
Subject: [PATCH] Support authentication via polkit
---
Programs/Makefile.in
On Thu, 28 Jan 2016, Samuel Thibault wrote:
--- a/Programs/brlapi_protocol.h
+++ b/Programs/brlapi_protocol.h
No need for a protocol change indeed, you can drop this spurious trivial change.
Thanks for the catch. Yeah, that isn't needed--at first I thought that it
would be necessary, then
On Thu, 28 Jan 2016, Dave Mielke wrote:
I have written a patch to allow polkit-based authentication for
brlapi.
Cool! Thanks. Your patch has now been committed to the repository. I've made a
few formatting changes so please verify that I haven't broken anything.
There are a couple of error pa
On Tue, 2 Feb 2016, Dave Mielke wrote:
Maybe the logSystemError("polkit_authority_check_authorization_sync")
should log the contents of error_local->message somehow.
What kind of string is in it? For example, does it contain any newlines?
Probably not; off-hand I don't recall ever seeing a n
Hi,
I thought that I'd added an example into brltty.conf.in to show how to
configure polkit, but apparently I forgot to do this. Patch attached.
Thanks,
-Mikediff --git a/Documents/brltty.conf.in b/Documents/brltty.conf.in
index 34ef415..05e37c7 100644
--- a/Documents/brltty.conf.in
+++ b/Docu
I'm trying to figure out if I can update brltty to 5.3.2 in the next
SLES/SLED service packs.
Thanks,
-Mike
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@mielke.cc
For general information, go to: ht
On Sat, 2 Jul 2016, Dave Mielke wrote:
I'm using a Vinux VM on my Mac. BRLTTY displays the message in the
subject line instead of what's on the screen. How do I fix it?
Brltty shows "screen not in text mode" when your system is switched to a
graphical console and a graphical screen reader (lik
On Sun, 3 Jul 2016, chrys87 wrote:
this is because brltty doesnt respect the installation path of arch
if you do a
sudo ln -s /usr/include/speech-dispatcher
/usr/include/speech-dispatcher/include
before compiling it it will work
it would be cool if that path (/usr/include/speech-dispatcher
)
On Fri, 8 Jul 2016, Dave Mielke wrote:
Newer Speech Dispatcher releases have a .pc file whereas older ones don't. This
shall finally be handled in brltty's configure script, but, in order to make
the fix as general as possible, do any of you know if eSpeak and/or Festival
Lite also now have a .p
On Thu, 7 Jul 2016, Amanda Lacy wrote:
I'm able to cat the brlapi.key file. My user is in the sudo group and
the file is associated with root. Can you think of anything else I
might check? Thanks.
Sorry for not answering sooner. You can get orca to generate a log that
will tell you if it's ha
On Mon, 29 Aug 2016, kendell clark wrote:
hi
Boy do I feel stupid. I don't have to create a new group or do any of that
other stuff I talked about. Brltty already provides a group called brlapi I
can work with. This simplifies things enormously. I'll just change the
permissions on the file d
Hi Kendall,
I just remembered that the Makefile might not automatically install the
policy file. You might need to manually copy
Authorization/Polkit/org.brltty.policy to a place where polkit would
expect to find it (/usr/share/polkit-1/actions perhaps).
On Mon, 29 Aug 2016, kendell clark wr
33 matches
Mail list logo
