In December, I found the mono port in a state where it only built with the
(deprecated) mcs compiler, and it would catch a SIGABRT predominantly when
exiting applications (including any call to the newer csc/roslyn compiler).
I've since made what seems like partial progress with mono's
Hi,
This is a diff to add a bunch of AMD Summit Ridge (17h) and Raven Ridge
PCI devices. It's in preparation of an upcoming diff for these that I've
worked on in collaboration with brynet@.
The link to http://www.pcidatabase.com/ in the comments for pcidevs
isn't retrievable anymore. I have
Hi,
It appears that HD Audio from AMD's generation Ryzen can't handle MSI.
This leads to the bug that I reported here:
https://marc.info/?l=openbsd-bugs=151648196215922=2
Disabling MSI resolves the problem on my current system which is a Raven
Ridge APU. I don't have the Summit Ridge hardware
On Thu, Jun 06, 2019 at 11:41:07PM +0200, Mark Kettenis wrote:
[...]
> It seems to work fine on my Intel Broadwell laptop. I haven't tested
> this on radeon(4) yet. So further testing, especially on systems with
> 4GB of memory or more is necessary.
>
> Please test.
Tested on a desktop with
On Tue, Jan 21, 2020, at 7:10 PM, Mark Kettenis wrote:
> The attached diff fixes amdgpu(4) and might very well fix radeondrm(4)
> as well.
[...]
For the record, this fixes running piglit with radeon on my HD7570 since this
was committed. It used to lock up on the test spec/arb_sync/sync_api,
On Sun, Sep 13, 2020 at 09:23:36AM +0100, Laurence Tratt wrote:
> Since I recently opened my big fat mouth and suggested that
> "kern.video.record" (analogous to kern.audio.record) might be a good idea, I
I support this suggestion. I think the idea behind it is based on the
same concerns that led
On Wed, Jan 06, 2021 at 10:48:58PM +0100, Marcus Glocker wrote:
[...]
> The implementation as such looks fine to me.
> But I quickly gave the diff a spin before on amd64 using my PS
> controller, and the result is not what I would expect.
>
> With uhid, I can access the controller on
Hi timo
On Sat, Nov 21, 2020 at 08:10:03AM +0200, Timo Myyrä wrote:
> Hi,
>
> The last attempt at adding Kensington Slimblade trackball support seems
> to have stalled:
> https://marc.info/?l=openbsd-tech=147444999319756=2
Thanks for digging this up. I got a Slimblade, but have been using
_lookup(dev_t dev)
#if NFIDO > 0
else if (cdev->d_open == fidoopen)
cd = _cd;
+#endif
+#if NUJOY > 0
+ else if (cdev->d_open == ujoyopen)
+ cd = _cd;
#endif
else
return (NULL);
Index: sys/dev/usb/uhid.h
=
Hi,
This diff adds support for the XBox One gamecontroller in a similar way
to what we have for the (older) XBox 360 controller [1][2]. This diff
is based on the pertinent code in NetBSD's uhidev.c.
Similarities include that the device doesn't provide a report
descriptor, so this diff adds one
On Sat, Jan 09, 2021 at 10:16:16AM +0100, Marcus Glocker wrote:
[...]
> So the problem doesn't seem to be in your new ujoy(4) code, but how the
> dev/hid/hid.c:hid_is_collection() function tries to cope with the PS4
> controller.
>
> I'm not much in to HID, but when I sync up the
On Sat, Nov 21, 2020 at 08:10:03AM +0200, Timo Myyrä wrote:
> Hi,
>
> The last attempt at adding Kensington Slimblade trackball support seems
> to have stalled:
> https://marc.info/?l=openbsd-tech=147444999319756=2
>
> I tested the diff and it still seems apply with little fuzz and works
> with
uhidev?"
.Cd "umstc* at uhidev?"
@@ -73,6 +74,7 @@ only dispatches data to them based on th
.Xr ucycom 4 ,
.Xr ugold 4 ,
.Xr uhid 4 ,
+.Xr ujoy 4 ,
.Xr ukbd 4 ,
.Xr ums 4 ,
.Xr umstc 4 ,
Index: share/man/man4/ujoy.4
===
RCS file: share/man/man4/ujoy.4
diff -N
On Sat, Jan 09, 2021 at 10:16:16AM +0100, Marcus Glocker wrote:
> On Thu, Jan 07, 2021 at 08:20:35PM +0100, Marcus Glocker wrote:
>
> > > I have heard from others who tried the diff that the PS4 controller is
> > > causing problems with the way it attaches. I ordered one to trial-and-
> > > error
On Sat, Jan 09, 2021 at 10:50:35AM -0700, Thomas Frohwein wrote:
> Hi,
>
> This diff adds support for the XBox One gamecontroller in a similar way
> to what we have for the (older) XBox 360 controller [1][2]. This diff
> is based on the pertinent code in NetBSD's uhidev.c.
&g
On Fri, Jan 15, 2021 at 06:32:04AM -0700, Thomas Frohwein wrote:
> On Sat, Jan 09, 2021 at 10:50:35AM -0700, Thomas Frohwein wrote:
> > Hi,
> >
> > This diff adds support for the XBox One gamecontroller in a similar way
> > to what we have for the (older) XBox 360 c
On Sun, Aug 22, 2021 at 09:50:15PM -0500, joshua stein wrote:
> On a particular laptop with a touchpad behind ihidev, dwiic would
> report a timeout every time it had to fetch touch data:
>
> dwiic0: timed out reading remaining 2
>
> On re-reading the i2c HID spec, the size supplied by
On Mon, Aug 23, 2021 at 08:57:59AM -0500, joshua stein wrote:
> On Sun, 22 Aug 2021 at 22:37:51 -0600, Thomas Frohwein wrote:
[...]
> > I thought I had the same problem on my new Asus Expertbook B9400CEA.
> > During boot, while reordering libraries and later it would print:
> &g
On Thu, Sep 16, 2021 at 12:11:24AM +0200, Mark Kettenis wrote:
> > Date: Wed, 15 Sep 2021 17:29:39 +0200 (CEST)
> > From: Mark Kettenis
> >
> > The diff below is a preliminary diff to fix a suspend/resume issue on
> > recent Thinkpads. This needs testing on a wider range of laptops to
> > make
On Thu, Mar 17, 2022 at 10:58:21PM +0100, Solene Rapenne wrote:
[...]
> >
>
> ping
>
> this diff is still applying to the kernel and allows to use a popular
> and affordable game controller
The diff was written fairly conservatively based on pre-existing code
and NetBSD's solution. It would
On Sat, Mar 19, 2022 at 09:15:23PM +0100, Stefan Sperling wrote:
[...]
> > + /* XBox One controller initialization */
>
> Shouldn't this initialization code be under #ifndef SMALL_KERNEL,
> like the rest of the code your patch is adding to this file?
>
> > + if
On Fri, Sep 08, 2023 at 08:55:10AM -0300, Lucas de Sena wrote:
[...]
> Quoting from `xenocara/app/xclock/xclock.c`:
>
> > {
> > /* force reading of XErrorDB into memory to avoid adding "rpath" to
> >pledge below */
> > char buf[1];
> >
> >
Very basic pledge(2) for the whole program. I didn't dive too much into
the details and maybe this can be refined some more. This is kind of a
product of me trying a tool I made `abstain` [1] for usefulness of
pledge(2) execpromises and it helped quickly find that xeyes(1) can run
with a very
On Fri, Nov 04, 2022 at 04:22:55PM +0100, Mark Kettenis wrote:
> > Date: Sat, 5 Nov 2022 02:06:11 +1100
> > From: Jonathan Gray
> >
> > On Fri, Nov 04, 2022 at 09:10:52AM -0500, John Browning wrote:
> > > Hi,
> > > I noticed I did not have sound on my new thinkpad which has a newer
> > > Intel
On Tue, Feb 07, 2023 at 08:51:40PM +1100, Jonathan Gray wrote:
[...]
> > ...
> > i915_resize_lmem_bar: stub
> > panic: kernel diagnostic assertion "pdev->pci->sc_bridgetag == NULL"
> > failed: file "/usr/src/sys/dev/pci/drm/drm_linux.c", line 1277
> > ...
>
> The vga arbiter bits need to
On Mon, Feb 13, 2023 at 08:40:22PM +1100, Jonathan Gray wrote:
> On Sun, Feb 12, 2023 at 02:25:47PM -0500, Thomas Frohwein wrote:
> > On Tue, Feb 07, 2023 at 08:51:40PM +1100, Jonathan Gray wrote:
> >
> > [...]
> > > > ...
> > > > i915_resize_lm
On Fri, Feb 03, 2023 at 12:54:52PM +1100, Jonathan Gray wrote:
[...]
> > +xehp_load_dss_mask: stub
> > +xehp_load_dss_mask: stub
> > +intel_slicemask_from_xehp_dssmask: stub
> > +intel_slicemask_from_xehp_dssmask: stub
> > +i915_gem_stolen_lmem_setup: stub
> >
On Sat, Feb 04, 2023 at 01:24:42PM +1100, Jonathan Gray wrote:
[...]
>
> I've committed the i915_gem_stolen_lmem_setup() portion.
>
> Another diff
>
> likely some more iomap use will show up later
>
> i915_gem_object_read_from_page_iomap()
> i915_gem_object_map_pfn()
> i915_gem_object_map()
On Mon, Jan 30, 2023 at 09:32:08PM +1100, Jonathan Gray wrote:
> The current generation of Intel Arc branded graphics cards are part of
> what drm and Mesa refers to as DG2.
>
> https://ark.intel.com/content/www/us/en/ark/products/codename/226095/products-formerly-alchemist.html
>
> In -current
On Mon, Jul 03, 2023 at 11:22:45AM +0200, Marc Espie wrote:
> I hope Vladimir will find the time to complete this answer.
>
> As far as Vlad's work goes, he did a presentation last week-end:
> https://www.lre.epita.fr/news_content/SS_summer_week_pres/Vladimir_Driver_OpenBSD.pptx
>
> (sorry for
On Sat, Aug 05, 2023 at 11:27:24PM +0200, Marc Espie wrote:
> Some comments already. I haven't looked very closely.
> On Sat, Aug 05, 2023 at 03:12:18PM -0400, Thomas Frohwein wrote:
> > The current draft hijacks post-extract target, but it would be easy to
> > add this to _pos
b38.tar.gz)
= 2417905
Index: Makefile
===
RCS file: /cvs/ports/games/fna/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile15 Jul 2023 23:24:35 - 1.17
+++ Makefile5 Aug 2023 19:10:00 -
@@ -7,21 +7,16 @@ HOMEPAGE =https://fna
On Mon, Aug 07, 2023 at 04:42:54PM +0200, Marc Espie wrote:
> I think it could be occasionally useful to know which variables have
> been defined in make.
>
> Incidentally, this DOES exist in GNU make, so I've reused the same name
> for basically the same functionality.
>
> I haven't checked
On Mon, Aug 07, 2023 at 06:59:15PM +0100, Stuart Henderson wrote:
[...]
> I haven't looked at other ports, but asterisk, vim and vmm-firmware do
> not use git submodules.
With vim, it's the way colorschemes are pulled in that *could* be
reworked using GH_SUBMODULES syntax. The old way continues
On Sun, Aug 06, 2023 at 07:00:49PM +0200, Marc Espie wrote:
[...]
> > > I'm also wondering if keeping the main GH_* stuff in bsd.port.mk makes a
> > > lot
> > > of sense, instead of grouping everything in github.port.mk
> >
> > I'm for it, maybe as a second step after the module for just the
>
On Mon, Aug 07, 2023 at 09:17:05PM +0100, Stuart Henderson wrote:
[...]
> I think maybe I'd prefer to have some variable that could be used
> *instead* of the existing GH_* variables rather than in conjunction with
> them (so they can be used for all GH archive ports, rather than have
> them a
On Tue, Aug 08, 2023 at 12:51:43PM +0200, Marc Espie wrote:
> Here's a revised diff (reordered plus actual use of the boolean)
> plus concrete example use for bsd.port.mk (disregarding the fact
> _ALL_VARIABLES would have to move *after* all MASTER_SITES have been defined.
I tested this on a
On Tue, Aug 08, 2023 at 01:02:53PM +0200, Marc Espie wrote:
> Actually, as far as bsd.port.mk, it doesn't need to
> move too much stuff around thanks to make's lazyness.
>
> Note that having a list of defined MASTER_SITES variables simplifies
> the check.
>
> I've also added a check for the
38 matches
Mail list logo
