Re: [BRLTTY] Focus Blue 5th gen and multiple bluetooth connections
On 2023-10-13 at 16:06 -0400, Dave Mielke wrote: > [quoted lines by Aura Kelloniemi on 2023/10/13 at 21:52 +0300] > >This seems to fix the issue. Now I'm able to connect to Focus Blue with two > >devices simultaneously. Thank you! > Thanks. The change has now been committed and will be in 6.7. Would you mind explaining what the issue was? As I Said, I'm not very familiar with bluetooth, and would like to understand this issue in case I encounter something similar in the future. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Focus Blue 5th gen and multiple bluetooth connections
Hi, > >Does anybody know about the details of the bluetooth protocol used by Focus > >Blue 5th gen? Dave? Is it possible that different hosts should connect to a > >different bluetooth channel? > I'm sorry for answering so late. Been away (in the hospital, actually) for > a while. Oh, that sounds tough. I wish you feel better now. > Add this line just under it: >descriptor.bluetooth.DdiscoverChannel = 1; > Then rebuild and see if the problem goes away. This seems to fix the issue. Now I'm able to connect to Focus Blue with two devices simultaneously. Thank you! -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Focus Blue 5th gen and multiple bluetooth connections
On Wed, Aug 16, 2023 at 08:22:40AM +0300, Aura Kelloniemi wrote: > Focus Blue 5th generation should support four simultaneous bluetooth > connections, but I have not been able to get that feature to work. I have > only tried with BRLTTY as I don't have any other software that would talk to > my display. [--] > Does anybody have a solution to this problem? It seems the answer is no. Does anybody know about the details of the bluetooth protocol used by Focus Blue 5th gen? Dave? Is it possible that different hosts should connect to a different bluetooth channel? I'm not very familiar with bluetooth/serial programming. Any ideas on what I could do to debug the issue? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] Focus Blue 5th gen and multiple bluetooth connections
Hello list, Focus Blue 5th generation should support four simultaneous bluetooth connections, but I have not been able to get that feature to work. I have only tried with BRLTTY as I don't have any other software that would talk to my display. My issue is that regardless of how many hosts I pair the display with, the host that connects first will be the only one served by my display. All other connecting hosts (BRLTTYs) fail with "Device or resource busy" error when they try to connect. There are no other apparent problems visible in BRLTTY logs that I have found. If I switch the active connection from my display's internal menu to be anything else than connection #1, I get no output from any paired host. Does anybody have a solution to this problem. I use multiple bluetooth hosts regularly and this is a real nuisance. Thsnks for any help! -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Focus Keyboard not working
Hi, Thu, Jul 13, 2023 at 09:02:00PM +0100, Life in Six Dots kirjoitti: > I cannot perform any commands on the braille keyboard. Do you know that the Focus keyboard can be locked (either intentionally or accidentally) by a certain key combination? See the Focus User Guide for details. It can be found online. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Cursor routing not longer working with kernel 6.3 on Debian testing
Hello, On 2023-06-27 at 07:09 +0200, Mario Lang wrote: > Nicolas Pitre writes: > > On Sun, 25 Jun 2023, Dave Mielke wrote: > >> I'm wondering if brltty shouldn't just set it automatically? > > The brltty package could install a file in /etc/sysctl.d/ to provide > > that config. This way it is more obvious. > I like that approach. It is obvious, and easy to change by the user if need > be. I like it too, but I think that distributions (such as Ubuntu) which include BRLTTY in the default installation are not likely to include this file as it affects every user's security. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Cursor routing not longer working with kernel 6.3 on Debian testing
Hi, On 2023-06-25 at 16:10 -0400, Dave Mielke wrote: > [quoted lines by Christian Schoepplein on 2023/06/25 at 20:59 +0200] > >For me it is OK to set > > > >dev.tty.legacy_tiocsti=1 > > > >in /etc/sysctlconf as a workaround like Rob suggested, thanks Rob for this > >hint! > I'm wondering if brltty shouldn't just set it automatically? Because TIOCSTI poses a security risk, I would prefer that BRLTTY would rather report to the user that TIOCSTI is disabled, instead of enabling it automatically. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] Problem connecting to Focus Blue V
Hi, I don't know if I'm doing something wrong, but I cannot connect multiple devices to my Focus Blue 40 V. All of the devices are running BRLTTY in Linux. I succeed in pairing all the devices with bluetoothctl, but if I have one BRLTTY talking to my display, no other BRLTTY can connect it – the error says: "Connection refused." Changing to a different connection from the internal menu of the device does not help. Actually, I always need to select the bluetooth connection with number 1 in order to use any of the paired devices. I am able to switch between Bluetooth and USB connection though. Has anybody gotten connection selection to work with Focus Blue V? How should it work? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] Window managers; was: Re: [OT] GUI applications not working when on text console
On 2023-04-10 at 18:22 -0400, "S. Massy" wrote: > Following that train of thought... What window manager(s) are you people > using besides marco? I assume it has to use GTK to be accessible via > Orca. I use Awesome as the window manager as it is scriptable. It is not accessible with Orca, but it works enough thanks to xbrlapi. The only things I use WM for are to launch either a terminal emulator or firefox. I use the terminal emulator to restart Orca whenever it hangs or misbehaves. Awesome is good for me as it is hacker oriented and very lightweight. I do all my real computing in console, and only start an X server if I really need to access a website that does not work with elinks or edbrowse. I too, hope that wayland accessibility would be radically improved, as it seems that there is soon no gooing back to Linux console as the console code is getting more and more outdated. Porting accessibility infrastructure and tools to Wayland is going to be a lot of work though and this is probably not going to be very interesting for any company. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Focus Blue 40 5th Gen experiences
Dear list, and sorry for the delay of my response, if somebody has been still waiting for it. I forgot. On 2022-10-22 at 14:48 -0400, "S. Massy" wrote: > On Sat, Oct 22, 2022 at 08:59:11PM +0300, Aura Kelloniemi wrote: > > I have been able to avoid ghost dots for several years already by placing a > > piece of micro-fiber cloth on the braille line, and by reading the display > > through the protective cloth. This very well avoids dust, grease and dead > > skin > > cells from getting inside the braille cells. > An absolutely fascinating idea that would never have occured to me. > Where do you get a sufficiently thin piece of microfiber cloth that it > will not impede your reading speed and how to your prevent it from > moving around as yor fingers glide on the display? I am a flautist and use the same type of microfiber cloth to cover the display as I use to clean the flute. It is very thin. At first I just wrapped the display in the cloth (buttons included, no problem). But a while back a sewer made a micro-fiber case for my display. It is like a pouch of the size of the display with both ends open. It has a sticker that is as wide as the display, so that the case can be made to fit more tightly or loosely. Now the cloth stays very well where it should be and no more becomes wrinkled even if I read very quickly. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Focus Blue 40 5th Gen experiences
Hello, On 2022-10-18 at 09:23 -0500, Devin Prater wrote: > Nope, besides the inevitable ghost dots that happen sometimes with > well-used displays. I have been able to avoid ghost dots for several years already by placing a piece of micro-fiber cloth on the braille line, and by reading the display through the protective cloth. This very well avoids dust, grease and dead skin cells from getting inside the braille cells. I have had some battery issues with Focus Blue 5th gen, and the firmware is far from perfect, but otherwise no problems. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] [OT] Braille display recommendation
Hi, On 2022-04-07 at 21:20 +0200, Mario Lang wrote: > Aura Kelloniemi writes: > > So if you have any remarks that might be useful for me (including possible > > deficiencies of the newest Focus Blue), I'm very interested to read. > Since the key layout of Active Braille and Active Star are pretty > similar, you already ruled out what I would have wnated to suggest. > I really like my Active Star 40, I reconsider the Actie Braille 2021, because it has many advantages. But am I right that the Active Braille series don't have an SD reader, which means that I would need to use a proprietary tool to transfer files to/from the internal storage, if I wish to utilize the note taker. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] [OT] Braille display recommendation
Hello list, This is an off-topic message for this list, as indicated by the subject. I am looking for a braille display to replace my Freedom Scientific Focus Blue. One candidate is the newer version of the same display, but I'd like to hear other people's recommendations for other options. I am looking for a display that is about 40 characters wide. I need bluetooth connectivity and long battery life. USB charging is ideal. The feature that I most appreciate in Focus is the great number of buttons is has for assigning to different operations. In addition to the braille keyboard and cursor routing keys, Focus Blue has 16 function keys. I have tested Brailliant BI 40X and Active Braille 2021, but I consider them to not have enough keys – Active braille's key layout is also not very ergonomic in my opinion, as the display has been designed to be used with the ATC mechanism, which is not very handy in terminal usage scenarios (and probably not available in BRLTTY). So if you have any remarks that might be useful for me (including possible deficiencies of the newest Focus Blue), I'm very interested to read. Thanks in advance! -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] BRLTTY and touch screen input for Braille?
On 2022-04-03 at 14:44 -0700, Rich Morin wrote: > I've been speculating about supporting touch screen input for Braille on > Linux-based cell phones. I have been thinking about this too. My vision has been that this would be completely independent of any screen readers, but of course screen reader support might make it more capable. > What I have in mind is a user-mode program (written in Elixir) that would > recognize input events and gestures, then send messages to various screen > readers. I don't know, but I assume that recognizing touch gestures has quite tight real-time requirements. I'm not sure if an interpreted and garbage-collected language is the best fit for this kind of task. > Can someone give me some clues about the most reasonable way to send these > messages to BRLTTY? For example, should I use uinput? Any other advice, > comments, or suggestions would be welcome. I think uinput is a good way to go. It may even be possible to make it so that it does not need BRLTTY's braille key translation, but can input straight to the Linux console (if that is where you want to run this). -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Modifying systemd units.
On 2022-03-16 at 16:40 -0400, Dave Mielke wrote: > There was a post, recently, showing how to resolve a problem by modifying > brltty's path unit. It showed how to do it by directly editing the > brtty.path unit file. While it isn't wrong to want to modify a systemd unit > file, directly editing that file is the wrong way to do it. For one thing, > the next update of that file, perhaps by upgrading the package, will lose > the change. So what's the right way? > What you should do is create a unit override file. You do this by first > creating the unit's override directory. It has the same name as the unit > file, but with .d appended to it. For example, the override directory for > brltty.path is brltty.path.d/. Within this directory, you an have as many > override files as you wish - just make sure that you give their names the > .conf extension. The easy way to do all this is $ systemctl edit e.g. $ systemctl edit brltty.path -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] BrlAPI for Haskell
Hi On 2022-02-11 at 02:30 +0100, Mario Lang wrote: > Working on a Haskell binding for BrlAPI. [--] > Reading the docs again, I am unsure if I want to mimick the low-level > API as much as I usually would. I think it would be better to have a > different type of handle for ttyMode operations. IOW, return some > handle from enterTtyMode and make writeText and friends use that. I noticed, that it is possible to enter raw mode from within TTY mode. After leaving raw mode, the connection is still in TTY mode. I think this needs to be considered, when making the decision you are talking about. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] brlapi__write and regionSize
Hello, If I call brlapi__write setting regionSize to -N (a negative interger), andMask and OrMask to NULL and text to something meaningful, BRLTTY writes only N characters from the text to the display and clears the rest of the display. If, on the other hand, I set regionSize to -1 * displaySizeInCells, I get the desired behaviour of writing as much of the text as possible, or padding, if necessary. I have an eery feeling that we did not discuss this properly last spring, when changes were made to brlapi__write. The current behaviour is a bit odd in my opinion. I think that truncation and padding should happen within the same region (either abs(regionSize) or displaySize). But currently truncation happens within abs(regionSize) and padding within displaySize (if regionSize is negative). I find this not to be logical. I suggest that we change this in either of the following three ways: 1) Pad/truncate text to the absolute value of regionSize, and don't clear the rest of the display. This way regionSize's value imposes a hard limit on the number of characters written, regardless of it being negative or positive, which is logical in my opinion. 2) Allow text to be longer than andMask and orMask and pad/truncate to the end of the display, not to the absolute value of regionSize. This will allow using brlapi__write to write arbitary length text to the display without first querying the display size, which reduces the number of redundant display size requests. 3) Treat negatie values of regionSize as in option 1, but add a special case for value 0 of regionSize. If regionSize is 0, don't allow andMask or OrMask to be used. Instead write as much of the text as possible, and pad to the end of the display, if text is too short. I think this option gives both the logical behaviour of option 1 and allows for writing arbitrary text without querying the display size. As discussed before, clients that want to write text (without knowing its length) most likely don't want to use andMask or orMask, so this would not limit clients' possibilities. So I'm for opption three. What do you think? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] BrlAPI for Haskell
Hello, On 2022-02-11 at 10:27 +0100, Mario Lang wrote: > Aura Kelloniemi writes: > > There are actually a few modes in which a BrlAPI connection can be. I would > > implement type classes for the common parts of these modes, and have a > > separate handle for each mode (at least basic, tty, raw and tty with raw > > keycodes). > I think the common operations can still use the initial handle. That depends on the state of the connection. For example when the connection is in raw or suspend mode, many operations just return an error. > Typeclasses are neat, but rather questionable without any underlying laws. That is the longstanding debate in the Haskell world about how to use type classes. I do not wish to dive deep into arguing about that, for example because I am not a mathematician and not an expert of the topic. But the laws don't necessarily need to be ery complicated. THe classes can be something like this: class HasDisplaySize con where getDisplaySize :: (HasBrlAPIConnection con, MonadIO m) => con -> m (CellCount, CellCount) I don't see how this is more questionable than type classes such as HasField or Storable which are part of the base package. Also it pretty much looks like the code style suggested by many industrial Haskell advocates. When a type class has only one method, there are no interactions between different methods and thus the associated law is more or less the type signature of the single method. As another example, brlapi__readKey returns a very different kind of value depending on the state of the connection. In tty mode it gives out a BRLTTY command with associated flags and other data. In raw tty mode the code is completely driver specific and cannot be decoded with the same logic as the BRLTTY command code. A safe interface to BrlAPI would make it difficult for the client to mix and match these different types of key codes on type level. Also, a safe interface might prevent the client from requesting a parameter value from the library, while the connection clearly cannot provide it. The point of type safety is to make invalid states non-representable, but due to the nature of BrlAPI, this is a challenging task. If you don't like overloading method names with type classes, there are other options, like creating separate connection handle types for most operations, and providing wrapper sum types, like this: getDisplaySize :: BrlapiConnectionWithDisplaySize -> IO (CellCount, CellCount) data BrlapiConnectionWithDisplaySize = BasicConnectionWithDisplaySize BasicConnection | TtyModeConnectionWithDisplaySize TtyModeConnection | DriverTtyModeConnectionWithDisplaySize DriverTtyModeConnection -- Note how there is no entry for raw or suspended mode connection so -- that those connections cannot be used to call getDisplaySize. However, we probably agree, that this style is horribly verbose and complicated for the client programmer, even though it is safer than using just one handle type. > > In addition I would export the low-level C functions from a separate > > module, > > in case somebody needs them, or the thick binding does not cover 100% of > > all > > possible API use cases. > Hmm, good point. The FII is already in a separate module, but I am > currently leaning towards not exporting that. Well, it can be exported as part of a .Internal module hierarchy so that API compliancy does not need to be a concern. > > I'm very interested in this project. I try to push my Rust bindings to > > github > > soon, after some clean up. Possibly Rust and Haskell can share some ddesign > > decisions. > While Rust and Haskell seem to be compared a lot lately, I personally > dont see the commonalities. The type systems of these languages are quite similar. BrlAPI operations are pretty simple – they are all IO actions, so purity goes out of the window together with laziness. Rust has its ownership system which allows swallowing any old connection handles when the connection changes mode so that the client cannot use stale old connection handles to make calls to BrlAPI. Linear and higher kinded types can be used to achieve a similar effect in Haskell. But yes, that is a significant differene. Of course the applications that utilize BrlAPI will most likely be quite different (and written in different style) depending on whether they are written in Rust or Haskell. BrlAPI, however, does not benefit a lot about higher level abstractions such as iterators or streaming. So basically I'm talking about type safety of the low-level BrlAPI operations and how to encode them with a type system that is somehow based on Hindley-Milner. It is completely a different story if we start to build a complete user interface layer on top of the basic device control interface provided by BrlAPI, but as far as I understand, this is not the topic no
Re: [BRLTTY] BrlAPI for Haskell
Hello, On 2022-02-11 at 02:30 +0100, Mario Lang wrote: > Working on a Haskell binding for BrlAPI. Excellent! > The following example works: [--] > main = withConnection "" ":0" $ \c -> do > dn <- getDriverName c > mi <- getModelIdentifier c > (x, _) <- getDisplaySize c > withTty c (Just 5) False $ \tty -> do [--] I'd make openConnection and enterTtyMode available too, not jsut the withSomeHandle-style functions. This way the application can discard the handles and create new ones at whatever point of the execution. This will also allow utilizing linear types in the future. > Reading the docs again, I am unsure if I want to mimick the low-level > API as much as I usually would. I think it would be better to have a > different type of handle for ttyMode operations. IOW, return some > handle from enterTtyMode and make writeText and friends use that. There are actually a few modes in which a BrlAPI connection can be. I would implement type classes for the common parts of these modes, and have a separate handle for each mode (at least basic, tty, raw and tty with raw keycodes). In addition I would export the low-level C functions from a separate module, in case somebody needs them, or the thick binding does not cover 100% of all possible API use cases. I'm very interested in this project. I try to push my Rust bindings to github soon, after some clean up. Possibly Rust and Haskell can share some ddesign decisions. I'm especially interested in how are you planning to handle the parameter API in a typesafe way, including the parameter state change callbacks. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Multi-column characters (was: Re: 6.5 soon)
On 2022-02-01 at 20:26 -0500, Nicolas Pitre wrote: > On Tue, 1 Feb 2022, Dave Mielke wrote: > > And what about my position that the default should be the way it is now? I > > want to make it easy for the actual language users. > Those users certainly have a braille table with definitions for all the > unicode characters they may encounter. According to Dave, users of Chinise braille at least always use contraction. I don't know about other Asian languages. > I think the default should be for wide characters that have no braille > representation (currently represented by a question mark) to span 2 > cells with blank padding by default. At least in that case the total > spacing will be right and things will properly align vertically. I'm against this. I have special braille glyphs for many emojis, but I still want the padding space (inserted by Linux) to be present after them. I'd like to have a separate setting for removing padding spaces, and I wish that this toggle does not affect BRLTTY's behaviour otherwise. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Multi-column characters (was: Re: 6.5 soon)
On 2022-02-01 at 15:00 -0500, Dave Mielke wrote: > [quoted lines by Aura Kelloniemi on 2022/02/01 at 21:43 +0200] > >What do you mean by corresponding single-byte characters? Are you talkig > >about > >characters which have a single-byte representation a particular character > >set > >or characters which have a single-column wide glyph? > Yes, it was a poor choice of words. I realized that after sending. I of > course meant width of 1. And my question was not complete. What do you mean by "corresponding?" Do you mean that Linux should add padding to a nearest narrow character. What if a line contains only wide characters? > >I wish Linux console would be fixed and upgraded for the 21st century so > >that > >it would have proper Unicode font support. More realistic probably is to get > >other terminal emulators to work with BRLTTY (or vice versa). > My opinion is that there should be a common shared memory rendering of the > screen content. Then other platforms, e.g. Chrome OS, could also benefit. I don't know how that would work permission-wise. I have planned to suggest that brlapi provided a simple interface through which terminal emulators could provide screen content to BRLTTY and accept input events from BRLTTY. Terminal emulators could then load brlapi with dlopen so that that the brlapi dependency would remain optional (which is probably important for distribution packagers). But this topic deserves its own thread. > >I think this is feasible. People probably don't feel much need to toggle it > >very often. > And what about my position that the default should be the way it is now? I > want to make it easy for the actual language users. I agree. > >Another question then is could we find a way to keep braille glyphs > >aligned on terminals that really support wide characters. I think this can > >be > >solved separately. > That'd be assuming a standard braille width, which isn't true. chinese > braille, for example, is doing roughly what PinYin does, i.e. a given > braille cell represents a discrete sound. Does this mean that chinise braille is implemented using Contracted braille in BRLTTY? If so, then standard braille glyph width of 1 cell holds as long as contraction is disabled. But there are other options too – like padding at the next word boundary (it works often in tables, but not always). -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Multi-column characters (was: Re: 6.5 soon)
Hello, On 2022-01-31 at 14:41 -0500, Dave Mielke wrote: > I guess we need to be able to live with the way Linux has done it even > though, in my opinion, it's the wrong way. Linux adds padding in the wrong > places, i.e. to the wide chracters. To achieve proper columnization, a > language that uses wide characters would introduce padding to the > corresponding single-byte characters where necessary. What do you mean by corresponding single-byte characters? Are you talkig about characters which have a single-byte representation a particular character set or characters which have a single-column wide glyph? I wish Linux console would be fixed and upgraded for the 21st century so that it would have proper Unicode font support. More realistic probably is to get other terminal emulators to work with BRLTTY (or vice versa). > No other platform has this strange issue so I think the best approach would > be to add a Linux screen driver parameter. Doing it that way wouldn't, at > least for the moment, make it settable from the preferences menu. I think this is feasible. People probably don't feel much need to toggle it very often. Another question then is could we find a way to keep braille glyphs aligned on terminals that really support wide characters. I think this can be solved separately. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Multi-column characters (was: Re: 6.5 soon)
Hi, On 2022-01-28 at 11:27 -0500, Dave Mielke wrote: > [quoted lines by Aura Kelloniemi on 2022/01/28 at 16:30 +0200] > >The option would allow removing paddig space after all multi-column > >characters. This is necessary for people reading Asian text. > Actually, no. That change was actually specifically made for those who read > Chinese. Having those kernel-inserted spaces wastes a lot of braille display > space, makes the braille rather difficult to read, and prevents contractions > from working. We "western" people tend to be a little arrogant, always > tghinking that we know what's best for others. Maybe you misunderstood my message. I want to make the current behaviour configurable so that both the old and the new behaviour are available. I don't want to make things more difficult to anybody (including people using Asian languages and myself). My point absolutely is not to tell anybody what is best for them. As can be seen from my message, I totally understand the need of stripping away padding spaces added by Linux – for people who read languages that utilize wide characters. There are (probably) many BRLTTY users who want to have their tables well-aligned even in environments where there are wide characters. It does not matter which group is a majority (Asian language readers or people interested in table alignment). We don't need to choose which group to serve, because we can easily serve both – by adding a configuration option. Please also note, that not all wide characters are letters – many are emojis and other symbols. These are the symbols that caused me misalignment issues (before I patched BRLTTY and removed the space-stripping feature which I do not need). -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] Multi-column characters (was: Re: 6.5 soon)
Hello, On 2022-01-21 at 12:27 -0500, Dave Mielke wrote: > I'm thinking of releasing 6.5 soon. Does anyone know of anything that still > needs to be fixed, have any last-minute requests, etc? Yes, the 'padding space removed after multi-column chaacters on Linux' problem still exists. Some people absolutely need this feature, and for some it is a nuisance. I would suggest making this configurable in the preferences menu. The option would allow removing paddig space after all multi-column characters. This is necessary for people reading Asian text. Linux VT automatically adds this space for some multi-column characters (but not for all, unfortunately). On terminals which properly display multi-column characters (I think all At-Spi2 terminals are in this category) there is no padding space after multi-column characters. But because these characters are not multi-column in braille, terminal alignment is messed up braille displays. BRLTTY should also offer an option to add a padding space after each multi-column character so that people who use graphical terminals and care about text alignment, still get their table columns right. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] [OT] Braille displays with firmware support for Unicode
Hi Sébastien, On 2021-11-10 at 17:37 +0100, Sébastien Hinderer wrote: > Have you considered, rather than looking for a device with the feature > you want, whether you couldn't find one that you could connect in > bluetooth to an Android phone where you may more likely be able to find > the features you would like? No, not really. I am quite concerned about the data leaks associated with proprietary Android devices. I know there is a fully open-source release of Android called LineageOS, but I don't know if BRLTTY runs on it. I also don't know whether the Google Talkback is a security/privacy risk. I'm not only suspicious about Google, but all proprietary hardware/software which has an internet access. Anyway, thanks for your suggestion. I'll consider it if I happen to find an answer to my open questions. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] [OT] Braille displays with firmware support for Unicode
Hello Mario, et al. On 2021-11-10 at 12:21 +0100, Mario Lang wrote: > I managed to put a Raspberry Pi 0w into my > Active Star a few years ago which would make building your > own note-taker pretty simple. How did you do this? How did you make it durable, and how do you supply power to the Pi? Of course I would prefer to have emacs as my note taker. The only thing holding me back is that I would not want to have a separate host device, which is always out of battery, or even worse, breaks in my backpack. Maybe, if I request for a company to put emaacs into my brave new display, things will go smoothly... > But dont wait for these manufacturers to support modern stuff like > Unicode Braille. They are stuck in their own world of catering to the > common deniminator of users. Supporting experts does not make money, so > they dont care. I really would like to hear objections. But you are probably right. All my bug reports have been silently ignored in all braille display maker companies that I have contacted so far. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] [OT] Braille displays with firmware support for Unicode
Dear list, I am looking for a new braille display and I'd like to ask your guidance, as you probably have the best information available. I would like to have a display, which has an integrated text viewer/editor. However, I am accutomed to use a non-standard braille table and find reading with the standard Finnish table to be inconvenient. I also am using a custom braille music notation format, which deploys 8-dot computer braille. To be able to read my music, I would need to have a display which supports Unicode braille. I would like to hear from you, is there any display on the market, which 1) has an SD card slot for transfering files 2) supports Unicode braille in text files in its firmware text viewer 3) supports editing Unicode braille in text files (i.e. typing Unicode braille patterns instead of regular text) 4) allows customizing the braille table used to display text in the firmware applications. I have taken a look at Focus Blue V, Active braille 2021 and Brailliant BI X40. I could not find an up to date manual for Active braille 2021, so I cannot know about that. The others at least do not support custom braille tables or Unicode braille editing, but I don't know about viewing Unicode braille. If there are no devices that support these features, I would like to know, if there are other people who would be interested. We could possible make a group request for these features and send it to braille display makers. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Regression: Making selection in BRLTTY clear X clipboard
Hi On 2021-11-07 at 18:12 +0100, Samuel Thibault wrote: > Aura Kelloniemi, le ven. 05 nov. 2021 14:48:55 +0200, a ecrit: > > I can try to provide more information, if needed. > Please pass -v to xbrlapi so we know what it's doing. xbrlapi sees all clipboard changes properly, it seems. It just does not seem to update X clipboard correctly. Attached is an xbrlapi output. I did the following things: - Started X - This starts xbrlapi, orca and brltty - Then 'termite' is started (a terminal emulatro) - Awesome window manager is started - I started LibreOffice Writer - I tried to paste with CTRL-V. It did not work. - I tried to paste with BRLTTY, it did not work. (BRLTTY does not seem to read clipboard contents from BrlAPI when started) - I selected some text and cut it to the X clipboard with CTRL-X - Now I could paste this text with CTRL-V or with BRLTTY - I switched to a VT and selected some text with BRLTTY - Now I can paste this text with BRLTTY - But I cannot paste the text with CTRL-V Also, orca announces all X clipboard events. When I select text with BRLTTY, it does not announce any clipboard changes. -- Aura new clipboard content from BrlAPI: 'Original text' 0x0001 (1) got focus xbrlapi: didn't grab window 0x0001 but got focus unknown got focus win 0x0064 created type 1f name Awesome WM_Sn selection owner window len 37 win 0x0065 created type 13b name awesome len 8 win 0x0066 created type 1f name Awesome systray window len 23 win 0x0067 created type 1f name Awesome no input window len 24 win 0x006d created type 1f name Awesome drawin len 15 win 0x0081 created type 13b name termite len 8 win 0x00a1 created type 13b name orca len 5 win 0x0083 created type 13b name len 1 WM_NAME property of 0x0081 changed type 13b name termite len 8 WM_NAME property of 0x0081 changed type 13b name termite len 8 win 0x008d created WM_NAME property of 0x0083 changed type 13b name aura@solaria:~ len 15 WM_NAME property of 0x0083 changed type 13b name aura@solaria:~ len 15 win 0x00600010 created type 1f name Awesome drawin len 15 0x0067 (6291463) got focus Awesome no input window got focus win 0x0060001b created 0x0083 (8388611) got focus aura@solaria:~ got focus win 0x0101 created win 0x0121 created type 1f name LibreOffice len 12 WM_NAME property of 0x0121 changed type 1f name LibreOffice len 12 win 0x0060001e created win 0x0142 created win 0x0142 destroyed win 0x0141 created type 13b name LibreOffice 7.2 len 16 win 0x0143 created type 13b name LibreOffice 7.2 len 16 WM_NAME property of 0x0141 changed type 13b name LibreOffice 7.2 len 16 WM_NAME property of 0x0141 changed type 13b name LibreOffice 7.2 len 16 win 0x0149 created win 0x01400016 created type 13b name LibreOffice 7.2 len 16 WM_NAME property of 0x0143 changed type 13b name VCL ImplGetDefaultWindow len 25 WM_NAME property of 0x0143 changed type 13b name VCL ImplGetDefaultWindow len 25 win 0x01400024 created type 13b name LibreOffice 7.2 len 16 win 0x01400025 created win 0x0121 destroyed win 0x0060001e destroyed win 0x0060001f created 0x01400024 (20971556) got focus LibreOffice 7.2 got focus WM_NAME property of 0x01400024 changed type 13b name Nimetön 1 - LibreOffice Writer len 32 Nimetön 1 - LibreOffice Writer got focus WM_NAME property of 0x01400024 changed type 13b name Nimetön 1 - LibreOffice Writer len 32 Nimetön 1 - LibreOffice Writer got focus 0x01400025 (20971557) got focus window without name got focus win 0x01400050 created type 13b name LibreOffice 7.2 len 16 0x06b0 (1712) got focus 0x0083 (8388611) got focus aura@solaria:~ got focus 0x06b0 (1712) got focus 0x01400024 (20971556) got focus Nimetön 1 - LibreOffice Writer got focus 0x01400024 (20971556) got focus Nimetön 1 - LibreOffice Writer got focus 0x06b0 (1712) got focus 0x0083 (8388611) got focus aura@solaria:~ got focus 0x06b0 (1712) got focus 0x01400024 (20971556) got focus Nimetön 1 - LibreOffice Writer got focus 0x01400025 (20971557) got focus window without name got focus 0x01400025 (20971557) got focus window without name got focus new clipboard content from X: 'New text from X' win 0x00a2 created type 13b name orca len 5 WM_NAME property of 0x00a1 changed type 13b name orca len 5 WM_NAME property of 0x00a1 changed type 13b name orca len 5 win 0x00a5 created type 13b name orca len 5 win 0x00a5 destroyed new clipboard content from BrlAPI: 'New text from BRLTTY in a text console' win 0x01402902 created type 13b name Tallenna asiakirja? len 20 win 0x00600025 created 0x01402902 (20982018) got focus Tallenna asiakirja? got focus 0x00600025 (6291493) got focus window without name got focus win 0x01402903 destroyed destroy: didn't grab window 0x01402903 win 0x01402902 destroyed 0x01400024 (20971556) got focus Nimetön 1 - LibreOffice Writer got focus win 0x00600025 destroyed 0x00600
[BRLTTY] Regression: Making selection in BRLTTY clear X clipboard
Hello, I'm using a self-built BRLTTY (6.4.r176.g9da8c89fe). It has a bug: whenever I make a text selection (i.e. use the CLIP_... commands) xbrlapi clears the X clipboard. BRLTTY clipboard is not affected, and works as expected. Therefore I expect this bug to be in xbrlapi. For example, if I select text in X (with keyboard) and copy this text to X clipboard, the text can be pasted normally (with keyboard or BRLTTY). But if I do any text selection with BRLTTY, the X clipboard becomes empty. So pasting with keyboard results in no activity. Pasting with BRLTTY is still possible, because it uses its own clipboard. I can try to provide more information, if needed. Thanks for your time! -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Multi-column characters on Linux
Hello, On 2021-10-04 at 13:03 -0400, Dave Mielke wrote: > [quoted lines by Aura Kelloniemi on 2021/10/04 at 19:29 +0300] > >Seems to work, thanks. (In fact I see more problems in some applications, > There might be another place (I foget off the top of my head) that also > needs to be changed which has to do with cursor placement. I'll look for it. > Now, how to parameterize it (if that's what should be done). Any ideas? Well, I thought about a preference in the Braille Presentation menu, but I'm totally fine with a brltty.conf parameter. A linux screen driver parameter might be a good options, because this is currently specific to just Linux. On the other hand, on all those terminal emulators which do not pad wide characters with spaces, there is a problem of misalignment as well. On those emulators BRLTTY should offer to add that space in order to keep consecutive lines properly aligned. If at some point BRLTTY works well for a graphical terminal emulator, I probably would use it, and I wish that alignment concerns were taken care of. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Multi-column characters on Linux
On 2021-10-04 at 10:51 -0400, Dave Mielke wrote: > [quoted lines by Aura Kelloniemi on 2021/10/04 at 15:50 +0300] > >I would also like to get rid of this space removal right away, because I'm > >debugging alignment issues, and I might provide misinformation to developers > >because of this. Could you please tell me the location of the code > >implementing this, so I can comment it out even before this is made > >configurable. > On line 1114 of the Linux screen driver you'll find: blanks = > getCharacterWidth(wc) - 1; > Try changing the value to 0 (i.e. as if getting the width returned 1 all the > time). Let me know if that does what you need. Seems to work, thanks. (In fact I see more problems in some applications, but I always prefer honesty over good impression.) -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Multi-column characters on Linux
Hi, On 2021-10-04 at 15:50 +0300, Aura Kelloniemi wrote: > On 2021-10-01 at 17:03 -0400, Dave Mielke wrote: > > On the screen, Linux pads a wide character with a space to the right. > This maintains vertical alignment, which is what they care about. > I reasearched this, and Linux does not do anything special with two-column > characters, not even padding them with spaces. Ah, sorry, I was wrong, and right too. And Dave, you also were wrong and right. Linux indeed pads some double-width characters with spaces. (According to a comment in drivers/tty/vt/vt.c this is done for Unicode 5.0.) I wonder if there is any chance of getting Linux to pad all double-width charactes with spaces. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Multi-column characters on Linux
Hi, On 2021-10-01 at 17:03 -0400, Dave Mielke wrote: > On the screen, Linux pads a wide character with a space to the right. This > maintains vertical alignment, which is what they care about. I reasearched this, and Linux does not do anything special with two-column characters, not even padding them with spaces. The behaviour you describe is done by editors and some other programs and it usually happens just, because the editor repositions the cursor after the user types in characters. So Linux displays the character as one-column wide, but the editor moves the cursor by two columns, because it thinks that the character is wide, and therefore it looks like as if there was an intentional padding space inserted. You can often demonstrate this by typing several wide characters in an editor (and see them be interspersed with spaces). Then, if you redraw the screen (often with CTRL+L), you can see that all the characters you typed are packed to the left side of the screen and all the padding space is put after the text. All the editors that I have tested (emacs, nano, vim) have serious issues with Linux not behaving as a proper Unicode-aware terminal. All of these editors have serious issues with cursor positioning and text on the screen becoming garbled when workign with wide characters. I actually would like to here, which editor people are using to write and read languages that utilize two-column characters. I'm afraid that people who use languages with combining characters really are in trouble, if they try to use the Linux console. These issues probably cannot even be worked around withouth switching to anoter terminal emulator. (This is because Linux prints the combining characters as a diamond, not understanding how these codepoints should be handled.) I have tried to work with people from emacs to enable a hack for linux that would prevent the screen from getting garbled. They are, however, very reluctant, and they want the Linux folks to fix this. But as you know, Linux console is sort of deprecated, and these problems will not be fixed. Here I provide a proof that Linux really does not understand two-column characters. This is a Bash session in a bare Linu console: $ echo $'ab\U0001F64Fxy\rabc' abcxy This prints letters a and b followed by a wide emoji, followed by letters x and y. Then it moves the cursor back to the beginning of line with \r and writes letters a b and c. These should override the first two letters and the first half of the emoji. This leaves the letters x and y in tact. But as you see, the c letter here overrides the whole emoji. If the emoji really was wide, then the output would be $ echo $'ab\U0001F64Fxy\rabc' abc xy Here the space represents the right half of the broken emoji. This later example is run in a VTE-based terminal that supports Unicode properly. > Brltty's Linux screen driver removes that space because retaining it makes > it very hard for those whose languages use wide characters, e.g. Chinese, > to read. Imagine how reading your language would be much more difficult if > there were a space after every single letter. Yes, that would be unacceptable. But my problem remains. I really care about the alignment, and my language does not use wide characters. Therefore I wish that this feature of removing a space is made a run-time configurable option. (It may happen, that a reader of Chinise would like to read a table, and they need to temporarily check which characters align vertically). Also, I'm afraid that this option can result in the the screen cursor and the cursor shown by BRLTTY to be out of sync. I would also like to get rid of this space removal right away, because I'm debugging alignment issues, and I might provide misinformation to developers because of this. Could you please tell me the location of the code implementing this, so I can comment it out even before this is made configurable. (If it is made configurable at all.) Thanks in advance! -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] Multi-column characters on Linux
Hi I am having a discussion with emacs developer about an emacs bug that is related to multi-column characters, e.g. many emojis. My first question is to those who have intimate knowledge about the Linux console: My understanding is that Linux has no support of any kind for displaying multi-column characters in a VT. Is this true? If not, what is this support? The second thing is related to BRLTTY's /dev/vcsu-support. If I write on the console a multi-column character followed by a space, BRLTTY does not show this space on the braille display, even when it is visible on the screen. So writing and a space in the console results only to the output of the emoji on the braille display. The cursor is not moved, and is incorrectly shown right after the emoji. If I set screen-parameters lx:Unicode=no in brltty.conf, this problem disappears. Of course this could also be a kernel issue in the /dev/vcsu-implementation. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-05-11 at 16:11 -0400, Dave Mielke wrote: > >Looks good. It's much more understandable now. > Okay, it's now merged into master. Great! But wait... I found this: brlapi_param_computerBrailleRowCells_t. Its definition is not in sync with the BRLAPI_PARAM_COMPUTER_BRAILLE_ROW_CELLS parameter. How does this work? At least the Java bindings seem to just expect that it is a uint8 array. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-05-11 at 13:33 -0400, Dave Mielke wrote: > Please check out the brlapi-parameters branch. What additional changes do > you think might be necessary. Looks good. It's much more understandable now. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-05-11 at 12:28 -0400, Dave Mielke wrote: > For all of them (including non-root parameters) or just for the server > version? What is a root/non-root parameter? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-05-11 at 17:24 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le mar. 11 mai 2021 18:18:56 +0300, a ecrit: > > Now my question is: why is .count set to 0 and .isArray to false for string > > parameterss, even though strings are arrays of characters. Shouldn't > > arrays of > > char and int get the same handling? > If they were really an array like BRLAPI_PARAM_RENDERED_CELLS, i.e. > indexed by something, yes. But strings are really a series of characters > that all go together, and bindings will usually completely distinguish > that from real arrays of characters. Ok, so this is again a question about semantic versus representational arrays. I am not trying to dictate the API, just wondering. I should now be able to write my parameter handling interface for Rust with the information that I received, and if the API changes, I will adapt to that. Thanks for all the answers! -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hi On 2021-05-11 at 09:52 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le mar. 11 mai 2021 09:49:04 +0300, a ecrit: > > And what about a field (at the end of the struct) that tells the maximum > > size > > of the parameter value array (in bytes or elements)? Or is there already a > > way > > to know how much space to allocate for a parameter value? > The current count field is to provide this information. > For variable values, brlapi_getParameter returns the actually needed > size, so you can re-allocate a bigger buffer. Or to avoid a round-trip > you can use getParameterAlloc which immediately allocates the proper > size. getParameterAlloc knows the maximum possible size of a parameter – it does not need to do any round-tripping. Is there a reason why this information couldn't be available somewhere – a global constant (BRLAPI_PARAM_VALUE_MAX_SIZE) or preferably per-parameter in its properties. Everything below considers the case where .isArray == true, until otherwise stated. If you are to add a flag which tells that an array has a variable size, couldn't the current .count field tell the maximum possible size? Or can the value be arbitrarily big (in which case unnecessary allocation should be avoided)? I am trying to find a way to make the API as simple as possible, but not so simple that it complicates bindings' writing. This is the reason I would like the maximum size to be easily available, and also why I would like to have uniform handling for all arrays – strings included. And then I'll ask about the case where .siArray == false: Shouldn't this too be very simple? The parameter will hold just one value – i.e. one int, one bool, one char, nothing that is variable-length. Do you disagree? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hi On 2021-05-11 at 09:57 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le mar. 11 mai 2021 10:01:35 +0300, a ecrit: > > How are strings handled in the parameters API? > > > > My initial thought was that string parameter values (as returned by BrlAPI) > > are const char* so that this pointer is contained into the parameter value. > > This would allow having a parameter that is an array of strings. > We don't use \0 over the wires, so we don't have arrays of strings, you > request for the different strings. I don't care about hte NUL so much – it is just convenience for C programmers, but other languages don't generally use it. Anyways, I was asking whether the string value is directly contained in the parameter (i.e. the parameter value is an array of characters) or is there one more pointer indirection. Dave answered this question, and there is no additional indirection. Now my question is: why is .count set to 0 and .isArray to false for string parameterss, even though strings are arrays of characters. Shouldn't arrays of char and int get the same handling? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hi again How are strings handled in the parameters API? My initial thought was that string parameter values (as returned by BrlAPI) are const char* so that this pointer is contained into the parameter value. This would allow having a parameter that is an array of strings. But now I came to think that most likely the parameter value contains the characters directly. This will not allow returning an array of strings. Which is right? If the second, could the parameter type be changed from a string to char, and the array handling would be applied to strings the same way as for all other array types – except that the terminating NUL is also counted as one element. I think this could be done in an ABI-compatible way. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hello I am happy that this sorts out. Should there also be can_watch flag? And what about a field (at the end of the struct) that tells the maximum size of the parameter value array (in bytes or elements)? Or is there already a way to know how much space to allocate for a parameter value? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-05-09 at 13:03 -0400, Dave Mielke wrote: > Okay. The bit about count actually being meanless when isArray is false > should probably be formally documented. +1 > Or, we could change count to something more intuitively obvious like > arraySize. +1 Will it then express the maximum size, or fixed size of the array? Or will it be different in different cases? I would want it to be visible in the parameter properties if the value may have a variable number of elements. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
On 2021-05-09 at 21:08 +0200, Didier Spaier wrote: > > I always wonder why people do in a graphical environment things more > easily done > in a console. Maybe just because that's what they are used to? Granted, > there > are things that can't be done in console, but typing commands in a shell or > editing text files isn't among them, as far as I know. > There are two problems with the console: 1) Linux console is broken (and almost unmaintained). Its Unicode rendering is totally broken – it does not understand multi-column characters at all. Linux console does not support full Unicode fonts either, and is limited to 512 glyphs which is very little. Quite often I am in a situation where I need to start a graphical shell to be able to show something to a sighted person. Linux's keybaord support in the console is also very poor – no shifted arrow keys, and so forth. 2) Quite many things in a modern Linux system expect there to be a running desktop session. Notifications, for example require a windowing system. Some times power management features are only enabled if the user is logged into a graphical desktop. This could be fixed, in theory, but will not be because there are not enough blind developers who would implement and maintain the required changes (which may be huge). That's why I wish there was a graphical terminal emulator (and a window manager) which would be as accessible as the Linux console is right now. But, alas, there is no. Orca is slow, and the whole At-SPI2 protocol is flawed so that BRLTTY and Orca cannot make the graphical world sufficiently accessible in its current state. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hello On 2021-05-09 at 05:46 -0400, Dave Mielke wrote: > [quoted lines by Samuel Thibault on 2021/05/09 at 11:36 +0200] > >> Some bindings might wish to use a list rather than an array. > > > >If bindings want to return a list, fine for them, "array" is just a word > >for the brlapi protocol, it can be expressed whichever way is fine for > >bindings. > They may wish to use an array for isArray==true but a list for > isArray==false. In other words, they may wish to use an array for a > multi-value result but a list for a multi-value single item. I think it's > healthy to make them aware of the difference. We are mixing different concepts now. I think that Samuel uses array as a term describing the data representation on the protocol level, whereas Dave uses it as a term to describe the logical language-level data type. What the client absolutely needs is: the basic data type of a single element in the parameter value – this is already provided. The client also needs the number elements in the parameter value – this should be provided by count, but it is not provided in case of strings. What the client does not necessarily need, but benefits from, is the semantic information on how to use/marshall/decode/encode this value. isArray alone cannot provide this information, as there are many languages with very different data types available – not just arrays and lists. For example one parameter (I don't remember which one) returns a bit vector, but this is not reflected in its properties in any way. My suggestion #1 is that if count == 0, the parameter contains a variable amount of values, and if it is positive, it contains exactly that many values. isArray is left for describing the intended logical use for the value – not its representation. My suggestion #2 is that count contains the number of values returned, if isArray == false. If isArray == true, then count contains the maximum number of values that may be returned/stored. My suggestion #3 is that we add more fields (or change existing ones) to describe more precisely the type of the parameter. If this is chosen, I suggest that we craft this system from scratch, and drop backwards compatibility in order to avoid creating more mess. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
On 2021-05-09 at 11:09 +0200, Samuel Thibault wrote: > But as I tried to explain in my first mail but apparently completely > failed: only makes the reading of other widgets *less* prioritized, > and not completely ignored. For braille that's fine enough since more > prioritized reading completely overrides the braille output. But > for speech these is no such thing as *overriding* priority, speech > dispatcher still reads everything that clients tell it, just in the > priority order. It currently does not have any way to know that there > are two screen readers, and only the messages of one of the two should > be actually spoken. Yes, ok, I did not read your message properly. Isn't Orca's speech support for terminals better than BRLTTY's? I believe it is more featureful, though syncing the braille display with speech output is not possible, if Orca does the speaking. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Fwd: Problems when using brltty in the terminal
Hi On 2021-05-09 at 09:23 +0200, halim.sa...@freenet.de wrote: > Yes, brltty should talk when a user enables speech. But It should _only_ > talk in xfce/mate/gnome terminals and not when > using the graphical desktop. Does it help if you set screen-parameters a2:Type=terminal in your /etc/brltty.conf? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-05-08 at 22:07 +0200, Samuel Thibault wrote: > Dave Mielke, le sam. 08 mai 2021 15:46:41 -0400, a ecrit: > > [quoted lines by Samuel Thibault on 2021/05/08 at 20:05 +0200] > > > > I personally think that that one (display size) shouldn't be marked as an > > array. > Ok. > I however eventually digged back into the git log, and this isArray > was really introduced to determine, as documented, whether there is > to be possibly several values, or always one. That's notably used in > the Python bindings to know whether it shall return, when one value > is returned, an array of one value or directly the value. That's > contradictory with what you wrote above. I don't think we want to > distort the original aim of the field, and keep it as is is. Which > indeed means that if isArray is not 1, count cannot be 1. As far as I know, all currently public API bindings that support parameters and utilize parameter property information are internal to BRLTTY. From the perspective of a binding writer, I wish that there is a clear and non-ambiguous mechanism of determining the number of elements in a parameter value. My opinion (if you are interested) is that count should tell the number of elements, always, unless the number is variable in which case count could be set to a special value, like 0 or -1. isArray should tell whether the data type is an array, rather than the values being conceptually separate – e.g. in Python the value would probably be a tuple, if the property's count > 1 and isArray == 0. > Actually I don't know what count is used for, we don't use it in the > client library or the server. Do you remember why you introduced it? I would like to use count for allocating the right amount of memory, and isArray for determining the data type for the memory contents. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hello Here is another fork of this thread regarding connection states. The BrlAPI reference manual explains the various connection states, but the API has been expanded since the documentation was written, and there are details missing. Looking at the server code, I noticed, that the server is not always strict about the connection state. For example it seems that the server can be queried for parameter values regardless of the connection state – at least I did not find any hard assertions preventing this. Anyways, the information that I am looking for is: - what packets can be sent/received in which mode, and - are the connection modes mutually exclusive – i.e. can the connection be in raw and tty modes simultaneously – i.e. the connection returns to TTY mode after leaving raw mode if TTY mode was active before entering raw mode. The reason why I ask these questions is Rust's type system: I want to help the client programmer by making sure that they cannot accidentally call invalid methods. The Rust compiler can prevent this, if the user-facing connection type changes with the connection mode. I.e. if the user holds a Connection object, they cannot call the write method, instead they need to call enter_tty_mode in order to acquire a Connection object which has a write method. In order to do this properly, I need to work out all the corner cases, like should Connectionleave_raw_mode return a Connection or Connection object or does it depend on the original connection state (before entering raw mode). Thanks in advance! -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
A quick follow up: On 2021-05-06 at 16:10 +0300, Aura Kelloniemi wrote: > - Or can I somehow get to know which parameters are read-only? Some of the > parameters are obviously rea-only (like the display size), but not all, > like > the used braille tables. Looking at the server code, I see that parameters can also be unreadable or unwatchable. It would be useful for me to have this information (either documented, or somehow acquirable programmatically). -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hello On 2021-03-26 at 22:45 +0200, Aura Kelloniemi wrote: > I have several questions about BrlAPI's internals: Now I'm working with the parameters. In order to take advantage of Rust's strong static type system I consider adding separate functions form getting/setting/watching for each parameter. This code generation can be automated with macros, so it will be less work than what it sounds. I hae some questions about the parameter system: - Parameter properties don't provide the read-only status information of a parameter. Could this be added? (Yes, aI know it breaks ABI.) - Or can I somehow get to know which parameters are read-only? Some of the parameters are obviously rea-only (like the display size), but not all, like the used braille tables. - brlapi_param_properties_t defines the parameter properties for all parameters. When type of a parameter is BRLAPI_PARAM_TYPE_STRING, the count member is not initialized (and thus will be zero). Shouldn't count be set to 1, if the parameter has a single value – like one string? - Is the isArray member in brlapi_param_properties_t somehow useful in parameter properties. If count is greater than 1, doesn't it mean that the parameter value is an array – or are there varaible-length arrays, and if so, how are they represented in properties? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-24 at 23:23 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le lun. 19 avril 2021 09:36:05 +0300, a ecrit: > > I think this is a very good idea. Could this operation also return the > > error > > message to the client? > Yes. This is now in. Great! I'll check it out. Thank you! -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-20 at 15:28 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le mar. 20 avril 2021 16:24:56 +0300, a ecrit: > > This probably means, than when text ends, the rest of the display is padded > > with spaces, and if space is defined to be something else than an empty > > cell, > > this pattern will fill the end of the display. > We could instead fill with U+2800? There was recently a discussion on this list where somebody wanted to redefine the unicode braille characters to display a single uniform dot pattern, which kind of would defeat this approach. Is it possible to set andMask to 0 for all the cells that need to padded in text, unless andMask (provided by te user) is long enough to take care of them? This way the cells are forced to be blank. This is what I did in my Rust implementation, but as BrlAPI does all necessary padding now, I'll start to utilize the server features. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-20 at 14:39 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le mar. 20 avril 2021 15:26:53 +0300, a ecrit: > They are completed with 0xff for and and 0x00 for or. This probably means, than when text ends, the rest of the display is padded with spaces, and if space is defined to be something else than an empty cell, this pattern will fill the end of the display. At some point there was a braille table included with BRLTTY than defined space to be dot 8, but now this table seems to be gone. > > I wonder whether it would be semantically clearer to blank only up to > > (regionSize * -1) if regionSize < 0, because we already decided that it is > > most likely a programming bug, > ? I thought we decided it would be considered a bug only if the > programmer provided a positive value, and when it is a negative value, > it means the programmer doesn't really care, and we just complete. Ok, this does not really matter to me, as my problem was related to full-display rewrites anyway. > > If an application uses regional writes, and another application "steals" > > the > > TTY from the original client, and later restores it, will the display > > contents > > be restored to original text the first client was showing? > Yes. Each client has its own buffer. Great. > If they were not, it would be a terrible mess, clients would have to > rewrite each time one switches focus, etc. Can an application force a complete refresh? I sometimes feel a need for this after a bluetooth conection issue. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-17 at 23:19 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le ven. 16 avril 2021 09:22:32 +0300, a ecrit: > > On 2021-04-16 at 01:04 +0200, Samuel Thibault > > wrote: > > > Such languages can then use brlapi__write with setting the charset, the > > > textSize, regionBegin set to 0, and regionSize with that flag or special > > > value. Is there something missing here? > > > > No, there isn't. This would be a working solution. > This has now landed! According to documentation, setting regionSize to a negative value blanks the rest of the display. If the masks are shorter than the number of cells until the end of the display, but text is longer than regionSize, what happens? I wonder whether it would be semantically clearer to blank only up to (regionSize * -1) if regionSize < 0, because we already decided that it is most likely a programming bug, if the masks do not match the text length (in code points). This is partly because the caller of brlapi__write uses masks to add/remove dots from particular characters, and to do that they need to know about the exact indices of those characters. Thinking about regional writes brought oen more question to my mind: If an application uses regional writes, and another application "steals" the TTY from the original client, and later restores it, will the display contents be restored to original text the first client was showing? If not, regional writes won't work as the parts of the display that are not refreshed will contain invalid information. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hi list, Samuel, thanks for all the additions. I'll incorporate them into brlapi-rs. The code is soon in the earliest pre-alpha stage (i.e. wraps most of the API) and I'll publish the repo on github. On 2021-04-17 at 16:33 +0200, Samuel Thibault wrote: > About asynchronous errors returned by write, I was thinking that we > could introduce a very simple SYNC packet, that does nothing except > returning an ack, but that will actually make a round-trip between the > server and the client, i.e. receiving the ack means one has received all > asynchronous errors. Programmers can thus call it after a brlapi_write > while hacking, to make sure immediately that the write is correct. Once > the code is good, the programmer can remove it to let the write be > completely asynchronous for performance. I think this is a very good idea. Could this operation also return the error message to the client? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-16 at 10:13 -0400, Dave Mielke wrote: > [quoted lines by Aura Kelloniemi on 2021/04/16 at 14:33 +0300] > >In the BrlAPI reference manual, specifically here: > >https://mielke.cc/brltty/doc/Manual-BrlAPI/English/BrlAPI-7.html#ss7.3 > Please, from several years ago already, no longer use mielke.cc/brltty/ - > brltty.app/ is the place to go. The old link is where I now stage things, > and, as such, isn't guaranteed to work, be reliable, etc. Of course, for > those who might want to check out a few (maybe controversial) things I've > written, I don't mind at all if they check out the main page of my server. Maybe you could write robots.txt file to try to stop Google from indexing the site, or part of it. I did not check the url that I was linking, this was just a result from an internet search engine. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-16 at 12:13 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le ven. 16 avril 2021 12:33:31 +0300, a ecrit: > > I read that it is possible to use enterTtyMode even when the client is > > already > > controlling a TTY. > ? Where did you read that? I believe that's not possible In the BrlAPI reference manual, specifically here: https://mielke.cc/brltty/doc/Manual-BrlAPI/English/BrlAPI-7.html#ss7.3 See the first packet type in the TTY handling mode list. > /* uhu, we already got a tty, but not this one: this is forbidden. */ > WERR(c->fd, BRLAPI_ERROR_INVALID_PARAMETER, "already having a tty"); I suggest that this behaviour is just documented in the reference manual, because the semantics are much clearer the way it is implemented than how it is documented. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-16 at 09:08 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le ven. 16 avril 2021 09:24:31 +0300, a ecrit: > > On 2021-04-16 at 00:49 +0200, Samuel Thibault > > wrote: > > > At worse another client is masking the output and getting all > > keypresses, > > > but if that client goes away your client gets back control of the tty. > > > > Can the client detect this situation somehow? > No. This would be a nice addition. Maybe a new read-only parameter could be added? > > Also, if the display is physically disconnected – or the braille driver is > > stopped – is there a way for the API client to detect this? > Yes, that's visible by monitoring the parameters (probably display size, > driver name, model, etc.) Ok, I try to test this. I read that it is possible to use enterTtyMode even when the client is already controlling a TTY. What happens if this call fails – will the original TTY be still available, or will the connection be dropped to the authentication mode? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-16 at 00:49 +0200, Samuel Thibault wrote: > At worse another client is masking the output and getting all keypresses, > but if that client goes away your client gets back control of the tty. Can the client detect this situation somehow? It would be useful to stop rendering while it is in vain. Also, if the display is physically disconnected – or the braille driver is stopped – is there a way for the API client to detect this? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-16 at 01:04 +0200, Samuel Thibault wrote: > Such languages can then use brlapi__write with setting the charset, the > textSize, regionBegin set to 0, and regionSize with that flag or special > value. Is there something missing here? No, there isn't. This would be a working solution. I'm a bit afraid though that brlapi__write becomes a very complex function to use, as it has already quite many special rules. But this will do for now. > I mean the library padding is useless since the server will have to do > it anyway in the case where the library didn't notice the size change > soon enough. Yes, ok. Then brlapi__writeText and friends can also be simplified. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-15 at 17:59 +0200, Samuel Thibault wrote: > Sébastien Hinderer, le jeu. 15 avril 2021 17:54:33 +0200, a ecrit: > > Perhaps we should rename it to brlapi_writeTextUTF16 then, withthe due > > deprecation logic? It'd feel more meaningful to me than a name talking > > aobut the OS. What do you think, Samuel? > "UTF16" will not ring any bell to windows programmers. > And UTF16 is not used by non-windows programmers. Side note: Widow$ does not actually use UTF-16. Window$' characters are arbitrary 16-bit integers which may or may not denote a valid UTF-16 sequence. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-15 at 08:55 -0400, Dave Mielke wrote:
> [quoted lines by Aura Kelloniemi on 2021/04/15 at 15:36 +0300]
> >If brlapi__writeTextUtf8 is added so that it does not rely on the
> >NUL-terminator but has a size parameter, I am done with this discussion.
> Well, I think it should be easy to write a UTF-8 string, and easy shouldn't
> require the programmer to have to calculate the UTF-8 character count. The
> programmer should, in the simple case, still be able to pass nothing more
> than a quoted string.
Size is a dreaded word in this discussion because of its ambiguity. In the
paragraph quoted above, I used the word size to mean the size of the text
string in bytes, and not the number of Unicode code points it contains.
Anyways, for a C programmer it certainly is easiest to pass in a quoted
string, and let the library to call strlen on it. But a binding writer needs
to copy the user-supplied string to a newly allocated memory location in heap,
append the NUL byte, and then call the write function, if the write function
does not provide a size argument.
I paste here my implementation of brlapi__writeText which is quite complex,
because it avoids copying the input string, if it contains the right number of
characters. This works, but is inefficient. In the code below, write_generic
calls brlapi__write with parameter and result value marshalling. Self is the
wrapped BrlAPI connection object.
pub fn write_text>(, text: S, cursor: Cursor) ->
Result<()> {
let text = text.as_ref(); // Allow passing in a String object or a
string reference
let size = self.get_display_size_cells()?; // cols * rows
// Find the number of characters in text and the last index that will
fit the display.
let mut chars = 0;
let mut end_index = None;
for (idx, ch) in text.char_indices() {
chars += 1;
if chars == size {
end_index = Some(idx + ch.len_utf8());
break;
}
}
if chars < size {
// The text is too short for the display, and needs to be padded
let missing = size - chars;
// Copy text to an a 8-bit integer vector and pad it to fill the
whole display
let bytes_size = text.len() + missing;
let mut bytes = Vec::with_capacity(bytes_size); // Allocate vector
bytes.extend_from_slice(text.as_bytes()); // Do the copy
bytes.resize(bytes_size, b' '); // Pad text. Th character used here
does not really matter
// Use and_mask to hide all characters after the end of text
let mut and_mask = Vec::with_capacity(size); // Allocate andMask
and_mask.resize(chars, 0b_); // Pass all user text as is
and_mask.resize(size, 0); // Mask away everything after the real
text ends
self.write_generic(
None, // Display number
0, // regionBegin
size, // regionSize
Some(), // text and textSize
Some(_mask), // andMask
None, // orMask
cursor, // Cursor position
Some("utf-8"), // Character set
)
} else {
// Text either fit exactly or is too long. Pass a substring to
BrlAPI.
let end_index = end_index.unwrap_or_else(|| text.len()); // Choose
the last showable character's index or the text's length
self.write_generic(
None, // Display number
0, // regionBegin
chars, // regionSize
Some(_bytes()[..end_index]), // text and textSize
None, // andMask
None, // orMask
cursor, // Cursor position
Some("utf-8"), // Character set
)
}
}
--
Aura
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-15 at 12:24 +0200, Samuel Thibault wrote: > > Isn't this always the case? The display size can always change while the > > application renders the output or BrlAPI processes it. brlapi__writeText > > works > > this way – it does the padding/truncation on the client side. > And it shouldn't :) I feel a bit silly about this. I don't see any difference regardless of who does the padding: My thinking goes like this: Scenario #1: Server does padding. Application renders the text according to the display size (or does not care about the size, and just sends text). The client forwards it to server. [Display size changes here.] The server receives the text and notices, that the text and display sizes do not match. It can either pad/truncate the text or signal an error. It can of course do both – write what it can and tell that the write failed – just to make sure that the application notices the size change. Scenario #2: Client library does the padding. Application renders text, forwards it to the client library, which pads/truncates it to fit the estimated display size. [Display size changes.] The text arrives to the server, which notices the size does not match. It has the same three options as in scenario #1. Scenario #3: The application does the padding. The application pads the text to fit the display size, and forwards it to the client library, which passes it on to the server. Again, if display size has changed, the server has the same options as above. The padding/truncation can also be done to make the text fit any region size, not just the whole display size. When the display size changes, the region size may or may not be invalidated as well – depends on the change and application logic. In all the cases the best that can be done depends on the application's requirements. Samuel, am I missing something? Why do you think the library should not pad/truncate text? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-15 at 06:44 -0400, Dave Mielke wrote: > [quoted lines by Samuel Thibault on 2021/04/15 at 12:37 +0200] > >Still. If the end-programmer produced a mask that isn't of the same > >size of the text, it'll very probably be due to a bug, and it's better > >reported than silently truncated. > But that could be part of the common handling. It's still better for the > binding to be able to provide, without modification, it's sizes and let the > underlying C code reject it in a common way. This, to me, is a separate > issue from allowing the text and masks to need to match the region size. There are two requirements going on at the same time. On one hand the question is about BrlAPI's usability from C. From a C programmers view it is complete waste of resources to pass regionSize, andMaskSize and orMaskSize to brlapi__write, if they have the same value anyways. From the binding writer's perspective this makes much more sense. Similarly for a C programmer it makes sense to use NUL-terminated strings, but for all other languages it is pointless. In my opinion it is not a bad idea to sometimes have both interfaces – those that are most convenient for C programmers, and those that are easiest for the ones who call C through FFI. We don't need to change brlapi__write, if adding another function makes sense. But whether it makes sense, I'm no more sure. If brlapi__writeTextUtf8 is added so that it does not rely on the NUL-terminator but has a size parameter, I am done with this discussion. The reason why I initially said that I don't need it was that I didn't yet know all the semantics of brlapi__write. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-15 at 10:07 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le jeu. 15 avril 2021 07:58:23 +0300, a ecrit: > > Another option would be to introduce size values for the masks, in > > addition to > > the regionSize. > I do not really see the use of being able to pass different sizes. > That's most probably a sign of a bug in the application output preparing > code, which the programmer would rather want to catch. You are probably right. The only case where the programmer may not care about the size of the output is when they want to just send some text on the display, and hope that it fits. For example brltty-ttb and apitest work this way in some situations. For these kind of applications it is useful to just write something, and get at least some part of the written text shown on the display. These are the cases where teh client programmer does not necessarily know (or want to know) how many characters their output contains, and in these situations they call brlapi__writeText, which pads/truncates the output as necessary. But this function cannot be called safely from languages that are Unicode only. > > Also, this does not need to break the protocol, because padding can be > > applied > > in the C client library. > No, because the display may have changed size in between, so the padding > will not be enough. Isn't this always the case? The display size can always change while the application renders the output or BrlAPI processes it. brlapi__writeText works this way – it does the padding/truncation on the client side. I guess that if the display size changes, the write operation either fails or is applied partially (or part of the display won't be refreshed). -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-15 at 10:02 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le jeu. 15 avril 2021 08:03:30 +0300, a ecrit: > > I tried this with ignoreKeys, and now I get an Illegal instruction error > > instead of Invalid parameter. > Had you called enterTty before this? No I hadn't and realized my self that it was the problem. Now it works. I have a follow-up question: Are the key ranges (to be accepted or ignored) defined per-handle or per-tty? I.e. if I acquire a TTY, make changes to the accepted key ranges, drop the TTY and acquire a new one, what key ranges will be in effect in the new TTY? Then Another thing: can BrlAPI server revoke access to a TTY in some condition after it has already been granted – i.e. can the connection be dropped from tty (or raw or suspend) mode to the authentication mode without the client asking for it? This information is necessary for me to make decisions about types used in the higher level Rust interface. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-14 at 17:44 +0200, Samuel Thibault
wrote:
> Aura Kelloniemi, le mer. 14 avril 2021 18:26:04 +0300, a ecrit:
> > I wrote a test which tries to ignore the LNUP command:
> >
> > const brlapi_keyCode_t cmds[1] = { BRLAPI_KEY_CMD_LNUP };
> > brlapi_ignoreKeys(brlapi_rangeType_command, cmds, 1)
> >
> > but I get an invalid parameter error.
> BRLAPI_KEY_CMD_LNUP alone is not enough, you need to also specify the
> type of key with BRLAPI_KEY_TYPE_CMD otherwise it's not a complete
> keycode value.
I tried this with ignoreKeys, and now I get an Illegal instruction error
instead of Invalid parameter.
--
Aura
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-15 at 02:43 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le mer. 14 avril 2021 22:13:45 +0300, a ecrit: > > On 2021-04-14 at 14:27 -0400, Dave Mielke wrote: > “ > regionBegin = regionSize = 0; (update the whole display, DEPRECATED and will > be forbidden in next release. You must always express the region you wish to > update) > ” > We warned about forbidding that because we don't really want the > andMask/orMask to be only *implicitly* of size cell count. Think what > would happen if the display happens to get resized in the middle of all > of this. Very bad things, if the masks are provided, but nothing, if they are not. I would recommend disallowing the use of masks, if regionSize is zero. > But we do not want to pad by default, since existing applications may > have been using it to perform partial updates. To me it seems like if the number of code points in text does not match regionSize, and exception is triggered and nothing is written, so no application can benefit of passing too short text values. Supplying too short mask values will cause invalid memory access. > - add a flag field to brlapi_writeArguments_t, which requires bumping > the soname ABI compatibility *and* protocol version. Another option would be to introduce size values for the masks, in addition to the regionSize. This would be most scalable. Also, this does not need to break the protocol, because padding can be applied in the C client library. And when the padding is applied at the packet creation time, one extra allocation can be avoided. > I believe it'd better be at an intermediate layer, to keep the BrlAPI > protocol as simple as possible. Yes, sure. Maybe I should have been clearer in expressing, that what I want can be done in the client. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hi Davce, nice to have your opinion as well! On 2021-04-14 at 14:27 -0400, Dave Mielke wrote: > I might as well throw in my opinion: To me, it's the region size that should > define the cell count, and it's the exact cell count that matters. Text and > masks can be padded/truncated as necessary to fit the cell count. And, to > me, a region size of 0 could mean from begin to the end. I agree. > Using the text size to define the cell count is imprecise. yes, and it should not be used for that purpose, basicly because of UTF-8. > What a user typically wants to do is to write some text without worrying > about anything other than having it written. He/she expects the interface > to worry about things like truncating, padding, wrapping, etc. It's kind of > like expecting an HTML writer to need to know the precise rendering width. Yes, and that is what I am trying to acheive in my bindings. My secondary goal is to be as efficient as possible, and that's what I am after. I already have a working implementation, but it does extra scaning and copying, which could be avoided, if there was a low-level function in BrlAPI that is not so strict about text and mask sizes specified by the caller. But I can very well live without this addition. > As I see it, there really should be no need at all for a simple client > writer to ever need to ask the size of the display. How would you achieve that? The client needs to implement scrolling, because even the shortest messages don't fit on every braille display without wrapping. Well of course it is possible to develop a client library, which provides facilities for reading contiguous texts, for example, but it is already special-purpose. Such a library might not be ideal for writing a game, or a music notation editor. > The Tcl and Java bindings (which I maintain) hide all of this from the > user. I guess I need to take a look. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hello
This time my question is related to ignoring and acceptig keys and key ranges.
If I understand correctly, BrlAPI server holds a list of key ranges that the
client either wants or does not want to see. These are just plain numeric
ranges – no specific bit-pattern handling is performed on the server side to
specialize these ranges to BRLTTY commands or key syombols.
But if this is correct, how it is possible to ignore or accept some specific
command regardless of the flags? (As the flags are in the more significatn
bits of the key code value.)
It seems that I am missing some critical piece of information. I can't get the
brlapi__ignoreKeys function to work.
I wrote a test which tries to ignore the LNUP command:
const brlapi_keyCode_t cmds[1] = { BRLAPI_KEY_CMD_LNUP };
brlapi_ignoreKeys(brlapi_rangeType_command, cmds, 1)
but I get an invalid parameter error.
The documentation is scarce and from the code I understand that I am doing
something wrong, but I don't get what exactly.
Thanks for any help.
--
Aura
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-14 at 15:29 +0200, Samuel Thibault wrote: > Sorry, since I'm at work and thus answering without looking much, I > missed that we already had the text length in textSize, which precisely > avoids the concerns with using strlen(). That's what I meant we could > use. No problem. Your suggestion still has the problem with multi-byte character encodings. textSize holds the text size in bytes, not the number of code points. We cannot dereve the lengths of the masks from that number. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-14 at 13:48 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le mer. 14 avril 2021 13:28:35 +0300, a ecrit: > > Would it mean that everything starting from regionBegin until the end of > > the display is written, and the masks (if given) will need to hold > > (displaySize - regionBegin) bytes? > strlen(text) would provide the length of the masks. I am strongly against this, because 1) It explodes if text is in a multi-byte encoding (which it always is in case of Rust). 2) Because it requires text to be NUL-terminated (which it is not in Rust, so an allocation and a copy would be required for appending the terminator). The real number of code points in text could be used to detect the lengths of the masks, but then we are almost back where we left. Perhaps the idea of not-exact-length-masks is too complex to be expressed without a new function, that allows the caller to explicitly provide the lengths. However, not-exact-length text should be feasible with regionSize == 0, but with the requirement that the masks are not applied. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-14 at 11:58 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le mer. 14 avril 2021 12:51:51 +0300, a ecrit: > > So I'm asking, could the restrictions on text and mask lengths be lifted? > Perhaps we can make regionSize=0 mean that? I am not a fan of special-cased values, but this could work. Would it mean that everything starting from regionBegin until the end of the display is written, and the masks (if given) will need to hold (displaySize - regionBegin) bytes? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hi again, On 2021-04-12 at 19:31 +0200, Samuel Thibault wrote: > Yes, but strerror_r is available in posix 2001, and gai_strerror is not > said to be non-threadsafe, so I guess it means it has to be. I guess we > can thus safely assume that we can build a brlapi_strerror_r from that > that is threadsafe on all current systems. Great! I'll be using it once it lands. Another thing: The BrlAPI server is pretty strict about the lengths of various values passed to it for a write operation. E.g. it "throws" an internal exception, if the text to be written does not exactly match the size of the written region. Even though I appreciate correctness in every possible situation a lot, I would like to dispute the usefulness of this checking: Because it is non-trivial to find out the length of a text string, its length will be calculated in many places – in brlapi__writeText, in the server, maybe somewhere else before rendering to dots. At least the BrlAPI's calculation could be dropped, if the server accepted texts of any length, and in case the text is too long the server would truncate it, and if it is too short, the text would be padded with empty cells (which may be a different thing from the space character, depending on the user's braille table). This could be applied to the masks as well. andMask could be padded with the value 255 (not to interfere with anything else that gets written) and orMask could be padded with zeros. But why? Counting the length in BrlAPI client of course is not so time-consuming. But as I am writing a binding, which does not directly create the BrlAPI packets, but rather calls the brlapi__write function (which makes a copy of all input values), I need to do an extra copy all user-supplied arrays to pad them. I definitely want to support padding/truncation, so that the caller does not need to worry about passing too short input, as most likely what they want is that the rest of the display (or display region) will remain empty. Doing an extra allocation, copy and deallocation just to add some padding feels like waste of resources. I could of course create the write packet my self, and this way the extra copy done by brlapi__write would be elided, but I think that using brlapi__write is a much better solution to guarantee forward-compatibility. On the other hand, dropping this checking in the server (and adding padding/truncation there) would not negatively affect the client programmer. Of course it means that some minor rendering issues could be detected a bit later, but as most programmer already use BrlAPI functions which support padding/truncation, there is no loss of safety here. So I'm asking, could the restrictions on text and mask lengths be lifted? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-04-12 at 12:11 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le lun. 12 avril 2021 12:58:53 +0300, a ecrit: > > Could a new function brlapi_strerror_r be added that would be re-entrant? > We could define add this indeed. But the problems of strerror and gai_strerror not being re-entrant still apply, although the chances of hitting those races is significantly smaller than with brlapi-strerror, maybe. So Iassume, that the re-entrant version of brlapi_strerror needs to be behind some feature gate, or be re-entrant only on some systems. One another question: To what names does BRLAPI_MAXNAMELENGTH refer to? Anythign returned by BrlAPI that can be considered to be a name? (Key name, command name, driver name, model name, etc.) -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hi On 2021-04-12 at 08:41 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le lun. 12 avril 2021 09:33:33 +0300, a ecrit: > > Various BrlAPI functions return strings to the caller (in one way or > > another). > > What is the character set of these strings? Can I assume them to be UTF-8 > > or > > ASCII? > > > > To give examples: driver names, model identifiers, key names, key code > > descriptions, error messages from brlapi_strerror, etc. > They are all ASCII. Ok, thanks. I researched the error messages case, and I suspect that they might be encoded in whatever character set in the case of C library errors, because strerror might return a translated message, which is in the user's locale. I also found race conditions from brlapi_strerror. Its result buffer will be clobbered, if brlapi_strerror is called simultaneously from multiple threads. This function also calls strerror, which contains the same race condition by definition. I don't think there is a portable way of fixing it, but on GNU libc strerror_r should probably be used. gai_strerror probably has the same issue. Could a new function brlapi_strerror_r be added that would be re-entrant? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hello again! On 2021-03-26 at 22:45 +0200, Aura Kelloniemi wrote: > I am continuing my attempt to create bindigs for BrlAPI to the Rust language. > I have several questions about BrlAPI's internals: So I continue this series: Various BrlAPI functions return strings to the caller (in one way or another). What is the character set of these strings? Can I assume them to be UTF-8 or ASCII? To give examples: driver names, model identifiers, key names, key code descriptions, error messages from brlapi_strerror, etc. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hello, I return to this questions: On 2021-03-29 at 09:56 +0300, Aura Kelloniemi wrote: > Would it require changing the BrlAPI protocol to be able to pass the > exception > message to the client? It is a nuisance to restart BRLTTY and search the > logs. And I have one more about brlapi_expandKeyCode. I kind of understand what this function supplies to the caller in struct brlapi_expandedKeyCode_t, but there is one dark corner: the case of type == BRLAPI_KEY_TYPE_SYM. As far as I understand, if the key event corresponds to a Unicode symbol, cmd is set to 0 and arg is set to a Unicode scalar value. If the symbol corresponds to an X keyboard symbol, cmd is set to 0xFF00, and arg contains 8 bits of key symbol value. Questions: - Am I right in my observations? - Is there a named constant for this 0xFF00 somewhere? - Is 8 bits enough space for the key symbol value? - Are there other possible cmd/arg combinations that I did not list? - I can't compare the returned keysym arg to the constants defined in /usr/include/X11/keysymdef.h, because arg contains only the lowest 8 bits of the key symbol value. Is this intentional? - What would be the most accurate and porable way of extracting all information from a brlapi_keyCode_t value? brlapi_expandKeyCode or manually decoding the value? - Why is brlapi_argumentWidth() not exported, even if it is needed to fully decode a brlapi_keyCode_t? Its implementation contains undocumented information. (For example, see brlapi_common.h line 544.) -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
On 2021-03-28 at 22:32 +0200, Samuel Thibault wrote: > Aura Kelloniemi, le dim. 28 mars 2021 12:05:46 +0300, a ecrit: > > Shouldn't both of them use size_t? > We could do this but that would change the ABI, better leave this for > next time we really want to break the ABI for a strong reason. > That being said, int is asserted to be at least 16bits, I don't think > we'd ever need to handle > 32767 characters. Most likely not. I was just thinking about the fact that size_t is mostly used to count bytes of memory usage. But you are right in that it can well be delayed, if ever changed. > > - If the number of code points in text does not match regionSize, > > brlapi__write does not write anything to the display. > ? Aren't you getting an exception? Ah, I was calling brlapi__closeConnection after brlapi__write, and did not get an exception. I added a call to brlapi__leaveTtyMode, and now I see it. Would it require changing the BrlAPI protocol to be able to pass the exception message to the client? It is a nuisance to restart BRLTTY and search the logs. > > - Proposal: Could brlapi__write be extended to allow passing text as NULL > > (without triggering the current effect of releasing the display to the > > parent client). In this case andMask should also be NULL, and orMask > > would > > be used to write a dot pattern to the display. > In my memory I thought it was already the case, but apparently not. That > could possibly be more convenient indeed, see more below. It actually is. I was accidentally also passing charset to __write, and that is why it did not work. Now that I have exceptions enabled, there is more reason and consequence in the world. > > - Why does brlapi__writeDots go through all the trouble of decoding the raw > > dot pattern given by the caller to an UTF-8 sequence? It could just fill > > the > > text field with spaces, memset andMask to zero, and use dots as orMask. I > > have tested this, and it works. > It works for the braille output, but not for the text output, whenever a > braille device has one, that text will remain blank. I have never heard of such a device. Wow. Are they just virtual devices, or are there real ones as well? How does contraction and text display work together? > That being said, that could be handled on the server side, when > text==NULL we could fill the text part with the unicode patterns. That would be beneficial to the client programmer, but otherwise makes no difference. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hello, and may your Sunday be the most beautiful,
On 2021-03-27 at 15:09 +0100, Samuel Thibault
wrote:
> Aura Kelloniemi, le sam. 27 mars 2021 01:14:13 +0200, a ecrit:
> If you pass UTF-8 text to brlapi_writeText while the locale is non-UTF-8
> it will get a bogus result, as expected.
I just did not know how BrlAPI's character set handling works, and where the
conversion happens – i.e. is it the caller's locale or the server's locale
that matters. In my opinion nowadays it would be best that neither locale
affects the result, and everything would be just UTF-8 (in transport). But I
understand that backwards compatibility might be a concern.
> There is also brlapi_writeWText which just takes a wchar_t *, so
> independent of the locale.
Except that a portable client cannot know whether wchar_t is 2 or 4 bytes – it
depends on libc, so I stay away from it.
> We could add a brlapi_writeUTF8Text if needed.
I don't need it, as the generic write function allows to define character set.
But maybe somebody else needs, and maybe they ask for it, if they do.
> > Will the given tty path be prepended by tty numbers from other sources –
> > e.g.
> > the WINDOWPATH environemnt variable?
> It will, yes.
Doesn't this interfere with the screen reader's ability to control the
desktop. However, I notice that setFocus does not take a full path to a TTY
either, so maybe it is the intent that any screen reader / terminal
multiplexer manages only one level of TTYs, rather than a whole tree of them.
> > - Could the BRLAPI_ERROR_... constants form an enum type, or would it break
> > something?
> We could do this indeed, we'd still need to define the macros in case
> some existing code depends on that.
Wouldn't such a dependency be a corner case. Turning a macro to an enum
variant does not interfere with using it as an rvalue which is the intended
use case.
However, if you retain the macros, I wish that the macros would be initialized
from the enum variants, and not the other way around, as this is safer
approach. E.g.
enum brlapi_error_t {
BRLAPI_ERROR_SUCCESS = 0,
BRLAPI_ERROR_...
}
#define BRLERR_SUCCESS BRLAPI_ERROR_SUCCESS
#define BRLERR_... BRLAPI_ERROR_...
This would allow safely importing the enum to Rust (or other languages) as is,
without worrying about possible holes or duplicates in the value range of
brlapi_error_t.
Again I have some additional questions. This time they are mostly about the
brlapi__write function:
- Could the brlapi_writeArguments_t struct member pointers be defined as const
*?
- Why do regionSize and textSize have a different type from each other in the
above mentioned struct? Shouldn't both of them use size_t?
- If the number of code points in text does not match regionSize,
brlapi__write does not write anything to the display. I think that
brlapi__write should either write as much of the text as possible (with the
masks applied), pad the text with blanks to fill the region, or preferably
signal an error to the caller.
- Proposal: Could brlapi__write be extended to allow passing text as NULL
(without triggering the current effect of releasing the display to the
parent client). In this case andMask should also be NULL, and orMask would
be used to write a dot pattern to the display. This would be very beneficial
for clients who only want to write dot patterns. If text, andMask and
orMask would all be NULL, or the whole argument pointer is NULL, previous
output would be discarded and display would be released to the parent.
- Why does brlapi__writeDots go through all the trouble of decoding the raw
dot pattern given by the caller to an UTF-8 sequence? It could just fill the
text field with spaces, memset andMask to zero, and use dots as orMask. I
have tested this, and it works. If my proposal from the previous chapter
would be accepted, brlapi__writeDots could just set text to NULL and pass
only orMask.
Thanks again for answers!
--
Aura
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Low-level BrlAPI questions
Hi list, Thanks for the fixes Samuel! On 2021-03-26 at 22:51 +0100, Samuel Thibault wrote: > Aura Kelloniemi, le ven. 26 mars 2021 22:45:43 +0200, a ecrit: > > - What is the best way to write to the display if the input text is always > > UTF-8 encoded? (This is how Rust's strings work). > You can just emit UTF-8. Byt what happens if the user's locale uses some other charset and I write with brlapi__writeText? How does the charset field in brlapi_writeArguments_t work? What kind of charset names it understands? > > - What is the intended use of enterTtyModeWithPath? > It is meant for screen readers, that take control of a whole desktop. > For more rationale, see the “A pile of "paper sheets"” section of the > brlapi documentation. Will the given tty path be prepended by tty numbers from other sources – e.g. the WINDOWPATH environemnt variable? > > - It is not always clear who owns the data returned by BrlAPI functions. > For which function is this not clear? - brlapi__openConnection: it manipulates the settings struct passd as parameter - brlapi_strerror - Possibly some others, but I haven't found them yet I have digged information from the client source, but it would be good to get it documented. > > To me it looks like brlapi_error_location allocates new memory for > > each thread, but it is never freed. > It uses pthread_once(_key_once, error_key_alloc); that calls > pthread_key_create(_key, error_key_free); Yes, ok, great. Additional questions: - What is the displayNumber field in brlapi_writeArguments_t? - What happens if I replace my display with another unit with a different size while BrlAPI clients are running? (Assuming that the same BRLTTY instance finds the new display and takes control of it. I cannot test this now.) - Could the BRLAPI_ERROR_... constants form an enum type, or would it break something? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] Low-level BrlAPI questions
Hello I am continuing my attempt to create bindigs for BrlAPI to the Rust language. I have several questions about BrlAPI's internals: - Is BrlAPI thread-safe in the sense, that I can call all BrlAPI functions from different threads with the same handle in parallel? - What is the best way to write to the display if the input text is always UTF-8 encoded? (This is how Rust's strings work). - What is the intended use of enterTtyModeWithPath? How to use it? What does its return value mean? - Shouldn't enterTtyModeWithPath take the ttys argument as conast int* instead of just int*? - It is not always clear who owns the date returned by BrlAPI functions. I have assumed, that whenever a string is returned from BrlAPI (either directly or as part of a structure), the string is owned by BrlAPI and should not be freed. BrlAPI's documentation is not clear about this. - Does BrlAPI leak memory that is used by thread-local storage? To me it looks like brlapi_error_location allocates new memory for each thread, but it is never freed. I am very grateful for answers to these questions. Probably more will follow, when I dig deeper to the API. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Clearing display contents with BrlAPI
Hello list,
Dave Mielke writes:
> [quoted lines by Sébastien Hinderer on 2020/12/08 at 10:08 +0100]
> >To clear the display you could use the writeDots method and pass it as
> >many zeros as the display's size.
> The idea, I think, is that the user shouldn't need to know the display's size
> just to clear it.
Absolutely, but I have other points as well:
1) I checked how the C function behaves, and doing brlapi_writeText(0, "")
clears the display. I believe that Python should follow the C API here,
especially because the C API works logically in my opinion.
2) Python's writeText differs from the C method in other important respect: if
I write an empty string, but ask the cursor to be shown on the display, the
curosr placement is completely ignored as well. The C function happily places
the cursor wherever I want, even when the text string is empty.
3) I don't see the coherence of special casing writeText('') as a no-op to
which Sébastien points to. In Python an empty string does not mean a value is
missing, None is used for that. writeText uses (with non-empty strings)
_replace all_, and not _append to previous_ semantics, which perfectly makes
sense.
4) I am not clearing the display intentionally. It just happens that the data
I sometimes want to write happens to be empty. For example, if the user reads
a piece of text, and one of its lines is empty, the normal logic of the
application (i.e. writeText(lines[current]) ) does not work any more. IMO I
shouldn't need to special-case this.
So after all I consider the current writeText behaviour in Python to be a bug
or a misfeature.
--
Aura
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] Clearing display contents with BrlAPI
Hi,
I noticed, that if I use the Python method brlapi.Connection.writeText and
pass it an empty string, it is a no-op. I would have expected this to clear
the entire contents of the attached display. I don't know if the C method
works similarly. I think that writeText('') in normal operation replaces the
whole contents of the display, instead of appending to it, so passing an empty
string should replace the existing text with nothing.
What do you developers think, what would be the correct method of clearing the
display contents? The current behaviour leads to a situation where I need to
define a wrapper method which handles the special case of an empty text
argument separately, which is not a huge problem, just a bit inelegant.
--
Aura
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] FreedomScientific raw key codes
Hello, Samuel Thibault writes: > Aura Kelloniemi, le mar. 28 avril 2020 06:38:52 +0300, a ecrit: > > Aura Kelloniemi writes: > > Okay. I think I have found a bug. If I press multiple keys on my display > > (regardless of what those keys are), BrlAPI starts to give me very weird > > key > > events. > AIUI you fixed it today? Yes, fixed. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] strange behavior udev and systemd
Mario Lang writes: > Aura Kelloniemi writes: > > If I have many BRLTTYinstances running, will BrlAPI clients connect to > > the right BRLTTY (i.e. will the latest BRLTTY be able to override the > > BrlAPI server for the previously started instances)? > There is no way to automatically determine what the "right" BRLTTY > instance would be. It depends on what the user wants. Yes. > They will likely need to configure the no-api directive in the > respective brltty.conf to avoid conflicts. That is exactly my point. I'll go to further details with this explanation. Let's imagine two scenarios: 1) I usually connect my display with Bluetooth, but when its battery runs out, I plug the USB cable for charging. Now a new BRLTTY instance i started. But what if I had open BrlAPI connections? They are still open, but they are being served by the BRLTTY talking to the (now non-existent) Bluetooth receiver. Thus, I possibly need to shut down a whole X session to fix the problem. (At least that might be the easiest solution.) And if I restart all BrlAPI clients, they will stop functioning immediately when I unplug the USB cable. 2) I have two displays. I'm either testing a display or I am reading the same text with a friend. (The later is arguably a far-fetched scenario.) Now, if we want to use an application which communicates with BRLTTY via BrlAPI, we have a big configuration problem. It is manageable, of course, but it is not easy. The easy way to fix the scenario #1 is by the good old way of running just one BRLTTY instance, which has been configured with braille-device set to bluetooth:,usb:. This way there is just one BRLTTY, one BrlAPI server, and no configuration hassle at all. So what I am trying to ask is this: are we really sure that starting a new BRLTTY instance for every new USB braille display is a good idea? Mostly people will only use one display, and this scenario is best handled (IMHO) with one BRLTTY instance. If somebody wants to use multiple displays, they need to do manual configuration when connecting the new display, but at least they get to know that they also need to separately configure BrlAPI, if they want to use it. Another way of course would be to redesign BrlAPI's and BRLTTY's co-operation, so that one BrlAPI server could handle more devices than just one. This would be a lot of work though. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] strange behavior udev and systemd
Hello, Sébastien Hinderer writes: > Okay, thanks for the explanations! > So everything will work nicely with 6.2, I guess. Dave, even BrlAPI? If I have many BRLTTYinstances running, will BrlAPI clients connect to the right BRLTTY (i.e. will the latest BRLTTY be able to override the BrlAPI server for the previously started instances)? Or, if I have multiple instances of BRLTTY running, will applications using BrlAPI connect to the BRLTTY that was first started? Regardless of whether it is controlling any display or not. This second scenario is what has been happening, if I have understood correctly. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] strange behavior udev and systemd
Hi Dave Mielke writes: > [quoted lines by Aura Kelloniemi on 2020/11/24 at 18:46 +0200] > >This probably is not enough, if there is a "system-wide" instance of BRLTTY > >running, for example if if the main method of connecting one's display is > >via > >Bluetooth. > Only USB connections are managed by systemd. I don't know of any way (maybe > there is one that I don't know about) to automatically start brltty for a > given > Bluetooth device. Sorry of being imprecise. I meant that using BrlAPI will fail, if an automatic instance is started while there is already anther instance of BRLTTY running. This probably cannot be fixed easily. That is the reason why I want to disable the USB udev rules. i'm also afraid that this peculiarity is going to hit users who are not very experienced. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] strange behavior udev and systemd
Hi list, Dave Mielke writes: > [quoted lines by Alexander Epaneshnikov on 2020/11/22 at 01:32 +0300] > >if i unplug display and plug it back. new brltty instance can't > >connect to brlapi. i get this: > >ноя 22 01:27:14 alex-pc brltty[2549]: another BrlAPI server is already > >listening on 0 (file /var/lib/BrlAPI/.0 exists) > > > >i think udev can't fully shutdown previous instance. > Yes. Thanks. The udev rules for when systemd is being used have now been > fixed. This probably is not enough, if there is a "system-wide" instance of BRLTTY running, for example if if the main method of connecting one's display is via Bluetooth. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Blinking glyphs (was: Re: Unicode braille patterns)
Hello list, Dave Mielke writes: > [quoted lines by Aura Kelloniemi on 2020/10/22 at 23:12 +0300] > >I have, for many years, wanted to have the blinking capitals preference to > >be > >generalized, so that I could: > > > >1) Define myself which characters blink, > >2) Define some dots in a glyph as blinking. > Do you mean that, for each individual character, a text table should be able > to > define which of its dots should blink? Yes. > What about different blinking patterns? Do you mean that the different dots would be blinking in a different pace? That would be kind of cool, but I believe it would be quite a lot of effort for a small gain. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] Blinking glyphs (was: Re: Unicode braille patterns)
Hi I could not resist the temptation to speak up. Lars Bjørndal writes: > Just a thoght; could the braille pattern characters be set to blink on the > display, on request? Yes please, but please, may it be configurable. I have, for many years, wanted to have the blinking capitals preference to be generalized, so that I could: 1) Define myself which characters blink, 2) Define some dots in a glyph as blinking. I would use the feature 2 to distinguish between different accent types that letters can have. Dave would ask "Why?" and I am answering this question in advance: Because I personally feel that if the whole character is blinking, it is difficult to read it. It takes much more time for me to detect what the blinking glyph actually is, and it slows down my reading speed. On the other hand, if only one or two dots of a character are blinking, the other dots are always visible, and I can detect, the base type of the glyph – i.e. I notice that it is a letter, and I even notice which letter it is, but I'm not necessarily sure if it has an accent or not, before I see the blinking dot appear/disappear. Sometimes, if I read fast, it does not matter, but often I really want to know which accent it is, and I can detect this information from the blinking dots. Of course, I could always use DESCCHAR, but if I am reading a language which uses a lot of accents, I would need to check every letter for an accent, or make a special glyph for each accent+letter combination, for which there is no enough expression potential in a single braille cell. For people, who don't care about accented letters, I can find some other exampels that they might care about: for example circled, bold or italic letters exist in Unicode. These could be represented by adding a blinking dot 8 to base glyph. I have delayed sending this feature request, because I have been thinking that it would be a lot of work, but now that this blinking glyphs thing came up, I thought that it would be a good time to see, if there is anybody else who would want to have this kind of a thing. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] [OT] Re: Being notified when battery level is low
Hello list, Mario Lang writes: > P.S.: It appears the same things are coming up over and over again for > those of us who do not run a graphical desktop. Screen curtain and > battery status come to mind. Maybe it is time to actually write a tool > which somehow collects these small tasks into something that somehow > just works. I would love to have something like > apt install text-mode-junkie > It would make it easy to turn down keyboard and display backlight, play > a sound when battery is low and maybe offer current weather based on the > current IP address. Basically what GNOME 2 used to offer as applets. That would be nice. Applets for screen or tmux would be great, if somebody is willing to write some C code. Personally I really hate things which echo to my TTY and mess up the current foreground application's displayed content. Tmux working together with D-bus would be an ultimate solution, possibly combined with a working pulseaudio configuration. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Prompt matching, again
Hi Dave Mielke writes: > When prompt patterns are being used, should it match the whole line? That can > be done. Yes, I think so. Many shell prompts contain space by default. Then there are programs like ipython, which has the following kind of prompt: In [n]: whre n is the input line number. Defining "^In" as a prompt pattern causes a lot of things which are not prompts to match it. > This has now been fixed. This fix makes the previous issue - matching prompt > patterns against the whole line - easy to do. Great! Thank you very much. I'll check it out. BTW, I think I found memory leaks from the regex handling/prompt matching code, but I'm not entirely sure, because I don't know anything about BRLTTY's memory management. Should I report what I found? -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
[BRLTTY] Prompt matching, again
Hello list,
There are problems in the current prompt matching implementation. I'm now
talking about the regex matching, not the original approach.
I noticed the problems when I tried to define patterns which contain spaces,
and when I took a look at the code, I found the following loop from
cmd_navigation.c, line 495.
while (length < scr.cols) {
if (characters[length].text == WC_C(' ')) break;
length += 1;
}
This code essentially defeats all my attempts to match against a prompt which
contains spaces. This code should be disabled, when the regex matching feature
is in use.
Also, it seems that BRLTTY still falls back to the original prompt matching
strategy when I use the PRPROMPT command (but not when I use NXPROMPT). When
at least one prompt pattern is defined, PRPROMPT moves the braille window to
the previous line which either matches a prompt pattern or matches the first
word on the cursor line. For me this is highly undesirable. This prevented me
from noticing for a long time that my patterns don't actually work correctly.
--
Aura
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] BRLTTY, systemd and unprivileged user
Hi list, Dave Mielke writes: > [quoted lines by Aura Kelloniemi on 2020/08/23 at 11:48 +0300] > >But aren't there two things to test? > Yes, exactly! And I'd also like to test this on your system anyway, just to > be > sure that that part of the code isn't contributing to the problem. I'll send you the log off-list. > >The other thing to test is whether the systemd configuration works. As far > >as > >I understand, the brltty@.service defines the User, Group and > >AmbientCapabilities because systemd is capable for setting them for BRLTTY > >by > >itself. This I cannot test by running from the build tree, unless I install > >the systemd config files, which has nasty consequences on my system. > Okay, This is how I do it: Thank you for this explanation. I did not know about the service.d directory trick. > >crw--- 1 secret_user_name tty 4, 1 Aug 22 21:37 /dev/tty1 > Some hacker will figure it out! :-) Anyway, it looks good. I call them crackers. I leave figuring out this detail as an exercise for the reader. > So, just to get my understanding correct, when you start brltty as root, and > it > doesn't switch to an unprivileged user, is it having the tty1 access problem? > I'm confirming because it doesn't seem to make any sense. Yes, this is the case. I suppose, the fiddling with the capabilities somehow causes the root account not to be root anymore. As far as I understand, root (in Linux, nowadays) is a predefined set of capabilities. Could it be that when BRLTTY adds capabilities, it (implicitly) at the same time drops the normal root capabilities, and then it does not matter any more that the process has uid 0. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] BRLTTY, systemd and unprivileged user
Hi Dave Mielke writes: > [quoted lines by Aura Kelloniemi on 2020/08/23 at 01:21 +0300] > I think it's better to do this kind of testing using a text console so that > you > don't have the added complexity of knowing which brltty instance Orca is > connecting to. I don't use any graphical environments, except in special situations. > You don't need to install an experimental brltty in order to test it. > Instead, > just build it and then run what you just built by using the run-brltty script > in the top-level of the source tree. But aren't there two things to test? First thing is whether BRLTTY runs correctly, if it is started as root, and it changes the privileges it uses by itself. This can be tested by running it from the build tree. This is a good thing to test, because there are many people who do not (and don't want to) use systemd, so BRLTTY being self-sufficient is great. The other thing to test is whether the systemd configuration works. As far as I understand, the brltty@.service defines the User, Group and AmbientCapabilities because systemd is capable for setting them for BRLTTY by itself. This I cannot test by running from the build tree, unless I install the systemd config files, which has nasty consequences on my system. > Could you please send me all of your systemd-related files so that I can > have a > look at them? I will send you the Arch package that I built and used to install the broken BRLTTY. It can be extracted with GNU tar. > >I had brltty.path, brltty@.path, brltty@.service, udev rules, and sysusers > >and > >tmpfiles configuration files. > What's the path to your installed sysusers file for brltty? /usr/lib/sysusers.d/brltty.conf > I'm guessing that you have /etc/brlapi.key, and that it's owned by the brlapi > group. That, by the way, is exactly hw I do it. Yes. Attached in this message is the Arcj build script that I wrote and used to build the BRLTTY package. > >elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: group not joined: > >987(uucp) > This one is odd. Are your serial devices, e.g. ttyS0, owned by the uccp group > rather than by the dialout group? Maybe there are two (or more) "standards" > for > serial device ownership. They are owned by uucp and that seems to be what Arch udev rules do. Therefore it would be nice if BRLTTY's install did not enforce creation of a dialout group, because it being present on the system might make some other application believe, that they should use this group (which does not have any permissions anywhere). > >elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: cannot create > >directory: /run/brltty: Permission denied > This problem needs to be fixed. For now, maybe you should just manually > create > the /run/brltty directory. The solution will probably be for brltty@.service > to > use ExecPre to create it. Maybe using 'install -d -o brltty -g brltty -m0700 /var/run/brltty'. This does not fail if the directory already exists, but fixes its permissions if needed. > >BRLTTY fails to open /dev/tty1 (Permission denied) > I guess that's what "Lupa evätty" means. Yes, sorry, I did not notice that when de-translating other messages. > >even though it manages to join the group tty (/dev/tty1 is owned by my user > >and has group tty). > What are its permissions? Tle whole ls -l output line would be interesting to > see. In any event, this shouldn't be an issue if brltty is running as root. crw--- 1 secret_user_name tty 4, 1 Aug 22 21:37 /dev/tty1 > >The only group missing is dialout, because I already removed the systemd > >files > >shipped with brltty (to get it running as root). > That wouldn't remove brltty believing that it needs access to it. No, of course, but it should not have consequences except for one error message. Or if it does, it is another bug to be hunted. > >dialout should not be needed for screen access though. > It isn't - it's for serial device access. On your system, however, it seems > that the uucp group might be used for this. I'm actually very amazed that BRLTTY is so smart that it dug this information from the device node itself. Great work, I'd say. > That, however, may be why you aren't benefitting from the rule to fix the > /dev/uinput access problem. At that point I still had all the rules, so it should not be that. > Well, brltty can. It does so by retrying, which can mean that it'll connect > to > the device somewhat later than as soon as possible. That's why it depends on > that service - so that it'll start as soon as udev is ready. The problem of systemd-udev-settle (according to a sourcw I found using a well-known search engine) is that it blocks the system bootup process. Because BRLTTY
Re: [BRLTTY] BRLTTY, systemd and unprivileged user
Hello, Dave Mielke writes: > [quoted lines by Aura Kelloniemi on 2020/08/22 at 08:57 +0300] > >BRLTTY changes to user brltty:brltty, but for some reason the capability > >assignments don't work and the process is non-functional. > This should (must) be figured out. Please capture and post a debug log for > when > brltty starts up. Use -L/path/to/logfile, and -ldebug should be enough. I needed to return to a setup where I run brltty as root, because I needed to get other things done. Could you recommend me an easy solution which allows me to install and run BRLTTY with reduced privileges, and then return to the full privileges version (blindly) when it shows "No screen". I have a spare display available that I can use, but I probably cannot have multiple BRLTTYversions installed at the same time, because the systemd files need to be in place. > i'm wondering if you may have a mixture of older and newer systemd > units/files. Should not be. > Or, maybe, you have an incomplete setup. Which systemd-related files do you > currently have insalled? I had brltty.path, brltty@.path, brltty@.service, udev rules, and sysusers and tmpfiles configuration files. I also had the brltty user and groups defined, but the problem can be there, if systemd did not generate them properly. > The output from systemd status and journal would probably be helpful. elo 19 10:15:32 solaria systemd-wrapper[929]: BRLTTY 6.1 rev BRLTTY-6.1-438-gee5f2a06 [http://brltty.app/] elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: continuing to execute as the invoking user: brltty elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: capability not permitted: cap_sys_module elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: capability not permitted: cap_setgid elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: path not group readable: /dev/uinput elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: path not group writable: /dev/uinput elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: group not joined: 977(brlapi) elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: group not joined: 987(uucp) elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: cannot create directory: /run/brltty: Permission denied elo 19 10:15:32 solaria systemd[1]: brltty@-dev-bus-usb-003-004.service: Can't open PID file /run/brltty/brltty--dev-bus-usb-003-004.pid (yet?) after start: Operation not permitted elo 19 10:15:32 solaria systemd-wrapper[934]: brltty: cannot create directory: /run/brltty: Permission denied > >I have not found a way to prevent BRLTTY from changing the user without > >deleting the user or passing --with-privilege-parameters to configure. I > >would > >like to have a way o disable the UIDchange, something like > >--privilege-parameters=lx:user= on BRLTTY command line. > That'd be a way to bypass a distribution's security policy. Well, I mean I would like to do this as root. When I have root privileges, I can already defeat all security policies, if I want. I want to run BRLTTY with minimal privileges, but this kind of an option would be extremely handy for situations when something goes wrong. > >When I manage to run BRLTTY as root, it changes to the directory > >/var/run/brltty and tries to create device nodes there. However, /var/run is > >mounted with nodev flag by systemd, because of security reasons. As a > >result, > >BRLTTY does not have access to screen contents (or any other devices). I > >fixed > >this temporarily by setting writable-directory to /root/brltty-runtime/ > >brltty.conf. > Brltty shouldn't be creating those devices. Sure, it'll try, but what this > situation really means is that something about the setup is wrong. In this > case, I'm suspecting that it's runniog as an unprivieleged user but doesn't > have the needed group memberships. Again, a debug log would be helpful. This was quite easy to test. I almost lost display access completely during the process, but luckily not. The log file is attached as brltty-as-root.log. I run: # brltty -W /var/run/brltty -ne -l debug BRLTTY fails to open /dev/tty1 (Permission denied) even though it manages to join the group tty (/dev/tty1 is owned by my user and has group tty). > It could be that you didn't install the sysusers brltty.conf file. It > probably > means that the brltty user doesn't have its needed supplementary group list. The only group missing is dialout, because I already removed the systemd files shipped with brltty (to get it running as root). dialout should not be needed for screen access though. > For now, disable brltty's udev rules. I will, and I probably never need them, since I always use one display, and I want it to be managed by a single BRLTTY instance regardless of whether I'm using bluetooth or USB. > >systemd complains that br
[BRLTTY] BRLTTY, systemd and unprivileged user
Hello I have tried to run BRLTTY using its current systemd units (from git head). These are the issues I'm facing: BRLTTY changes to user brltty:brltty, but for some reason the capability assignments don't work and the process is non-functional. I have not found a way to prevent BRLTTY from changing the user without deleting the user or passing --with-privilege-parameters to configure. I would like to have a way o disable the UIDchange, something like --privilege-parameters=lx:user= on BRLTTY command line. When I manage to run BRLTTY as root, it changes to the directory /var/run/brltty and tries to create device nodes there. However, /var/run is mounted with nodev flag by systemd, because of security reasons. As a result, BRLTTY does not have access to screen contents (or any other devices). I fixed this temporarily by setting writable-directory to /root/brltty-runtime/ brltty.conf. When I attach my display using USB, a new BRLTTY process is started, but because it cannot access the screen contents, it is stopped again, and restarted. This process of starting and stopping loops endlessly. For some reason the writable-directory option that I configured in brltty.conf does not seem to take effect. Also it is not possible to disable executing these units, nor can they be stopped manually with systemctl. systemd complains that brltty@.service depends on systemd-udev-settle.service which is deprecated, and should no more be used. This is a bit vague bug report, but I can try to give out more information as needed. However, it is a bit difficult to debug this issue, because it is BRLTTY startup that fails, and because I cannot run BRLTTY in a virtualized ccontainer. I'm also not an expert when it comes to capabilities or systemd. My systemd version is 246 (246.2-2-arch) Build features: +PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
Re: [BRLTTY] Making postmarketOS blind-accessible
Dave Mielke writes: > [quoted lines by Rich Morin on 2020/08/19 at 12:37 -0700] > >feel free to contact me off-list with comments, suggestions, etc. > It'de be very cool for the kernel to have suppport for all known > USB-to-serial > adapters, plus any indirectly needed serial support, enabled. That way, those > with older braille devices that only have a serial port would benefit for the > mere extra cost of the adpater cable. Sure would beat having to purchase a > newer braille device. I guess that pmOS kernels don't have virtual console support built in. (It is mostly considered to be wasted memory on low-end devices.) This is the number one thing to have for any accessibility support. -- Aura ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
