Re: CVS: cvs.openbsd.org: xenocara
On Tue, Jun 04, 2024 at 05:57:02PM +1000, Jonathan Gray wrote: > On Mon, Jun 03, 2024 at 11:42:22PM -0600, Matthieu Herrb wrote: > > CVSROOT:/cvs > > Module name:xenocara > > Changes by: matth...@cvs.openbsd.org2024/06/03 23:42:22 > > > > Modified files: > > lib/libXpm : Makefile.am Makefile.in > > Added files: > > app/sxpm : Makefile > > > > Log message: > > Explicitely build sxpm in app, after the new libXpm has been installed. > > > > This makes sure it is linked against the new libXpm, not the existing > > one in /usr/X11R6/lib which may reference to an old, incompatible libc. > > ok tb@ > > needs to be added to app/Makefile as well Yes I forgot to commit the chunk for app/Makefile from my diff. Fixed, sorry. > > Index: app/Makefile > === > RCS file: /cvs/xenocara/app/Makefile,v > diff -u -p -r1.38 Makefile > --- app/Makefile 15 Aug 2019 17:01:12 - 1.38 > +++ app/Makefile 4 Jun 2024 07:47:41 - > @@ -5,7 +5,7 @@ SUBDIR= bdftopcf mkfontscale \ > appres beforelight bitmap editres fonttosfnt \ > iceauth ico listres luit oclock \ > rgb sessreg setxkbmap \ > - smproxy twm viewres x11perf xauth xbacklight xbiff xcalc \ > + smproxy sxpm twm viewres x11perf xauth xbacklight xbiff xcalc \ > xclipboard xclock xcmsdb xcompmgr xconsole \ > xenodm xdpyinfo xedit xev xeyes xf86dga \ > xfd xfontsel xgamma xgc xhost \ -- Matthieu Herrb
Re: CVS: cvs.openbsd.org: xenocara
On Mon, Jun 03, 2024 at 11:42:22PM -0600, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2024/06/03 23:42:22 > > Modified files: > lib/libXpm : Makefile.am Makefile.in > Added files: > app/sxpm : Makefile > > Log message: > Explicitely build sxpm in app, after the new libXpm has been installed. > > This makes sure it is linked against the new libXpm, not the existing > one in /usr/X11R6/lib which may reference to an old, incompatible libc. > ok tb@ needs to be added to app/Makefile as well Index: app/Makefile === RCS file: /cvs/xenocara/app/Makefile,v diff -u -p -r1.38 Makefile --- app/Makefile15 Aug 2019 17:01:12 - 1.38 +++ app/Makefile4 Jun 2024 07:47:41 - @@ -5,7 +5,7 @@ SUBDIR= bdftopcf mkfontscale \ appres beforelight bitmap editres fonttosfnt \ iceauth ico listres luit oclock \ rgb sessreg setxkbmap \ - smproxy twm viewres x11perf xauth xbacklight xbiff xcalc \ + smproxy sxpm twm viewres x11perf xauth xbacklight xbiff xcalc \ xclipboard xclock xcmsdb xcompmgr xconsole \ xenodm xdpyinfo xedit xev xeyes xf86dga \ xfd xfontsel xgamma xgc xhost \
Re: CVS: cvs.openbsd.org: xenocara
On Thu, Sep 07, 2023 at 03:54:21PM -0600, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2023/09/07 15:54:21 > > Modified files: > proto/xorgproto/include/X11: Xmd.h > > Log message: > Fix the build after recent CARD64 / unsigned long fises for llvm 16 > > There are many places in X drivers where CARD64 is used mixed with uint64_t > and CARD32 mixed with uint32_t. > Initially the CARD* types were only meant to be used in the X protocol > definition and implementation. Later they got used in driver for fixed- > length unsigned integers as synonyms for uintxx_t types. > Unfortunatly on OpenBSD the definition of uint64_t and CARD64 don't match. > So take the bull by the horns and fix the CARDxx definitions using the > corresponding uintxx_t types from stdint.h. > this was ok tb@ -- Matthieu Herrb
Re: CVS: cvs.openbsd.org: xenocara
On Thu, Sep 07, 2023 at 10:02:12PM +0200, Matthieu Herrb wrote:
> On Thu, Sep 07, 2023 at 05:24:56PM +0200, Matthieu Herrb wrote:
> > On Thu, Sep 07, 2023 at 07:11:40AM +0200, Anton Lindqvist wrote:
> > > On Wed, Sep 06, 2023 at 05:42:37AM -0600, Robert Nagy wrote:
> > > > CVSROOT:/cvs
> > > > Module name:xenocara
> > > > Changes by: rob...@cvs.openbsd.org 2023/09/06 05:42:37
> > > >
> > > > Modified files:
> > > > driver/xf86-video-amdgpu/src: amdgpu_present.c
> > > > drmmode_display.h
> > > > xserver/glamor : glamor.h glamor_egl.c
> > > >
> > > > Log message:
> > > > unbreak build with clang-16 by fixing up function definitions to match
> > > >
> > > > our uint64_t is an unsinged long long, but CARD64 is defined as
> > > > unsigned long
> > > > so the function pointer types in both glamor and xf86-video-amdgpu were
> > > > mismatched and clang-16 treats that as an error
> > > >
> > > > ok matthieu@
> > >
> > > This broke the tree. Here's a potential fix.
> >
> > Hmm no, this one reverts parts of the llvm 16 diffs.
> >
> > What about this that gets rid of CARD64 completely in this context ?
> >
> > hint for the X developpers: CARD64 and friends are normally reserved
> > for the X protocol specification and implementation
> >
> > All other uses as cheap substites for uint64_t or similar are just
> > historical artefacts from an era where there was no standard integer
> > types with known fixed lengths.
>
> This is still not enough.
>
> I've deciced to cure the problem at its root.
>
> Whith this patch, the tree builds with both base llvm and llvm 16 on
> amd64. I've started a build i386 to double check 32 bit arches.
>
> And it will allow to revert some other patches to reduce the number of
> local changes. I also think that it has some chances to be accepted
> upstreams.
>
> basically just define the CARDnn types in terms on uint_nn everywhere.
> Like for signal.h all systems still supported by X have stdint and the
> uintnn_t types.
>
If this builds please land it.
>
> Index: proto/xorgproto/include/X11/Xmd.h
> ===
> RCS file: /local/cvs/xenocara/proto/xorgproto/include/X11/Xmd.h,v
> retrieving revision 1.2
> diff -u -p -u -r1.2 Xmd.h
> --- proto/xorgproto/include/X11/Xmd.h 11 Nov 2021 08:55:42 - 1.2
> +++ proto/xorgproto/include/X11/Xmd.h 7 Sep 2023 16:20:01 -
> @@ -57,6 +57,8 @@ SOFTWARE.
> # include /* Solaris: defines _LP64 if necessary */
> # endif
>
> +#include
> +
> #if defined(__SIZEOF_LONG__)
> # if __SIZEOF_LONG__ == 8
> # define LONG64 /* 32/64-bit architecture */
> @@ -107,15 +109,10 @@ typedef short INT16;
>
> typedef signed charINT8;
>
> -# ifdef LONG64
> -typedef unsigned long CARD64;
> -typedef unsigned int CARD32;
> -# else
> -typedef unsigned long long CARD64;
> -typedef unsigned long CARD32;
> -# endif
> -typedef unsigned short CARD16;
> -typedef unsigned char CARD8;
> +typedef uint64_t CARD64;
> +typedef uint32_t CARD32;
> +typedef uint16_t CARD16;
> +typedef uint8_t CARD8;
>
> typedef CARD32 BITS32;
> typedef CARD16 BITS16;
>
> >
> > Index: src/drmmode_display.c
> > ===
> > RCS file:
> > /local/cvs/xenocara/driver/xf86-video-amdgpu/src/drmmode_display.c,v
> > retrieving revision 1.4
> > diff -u -p -u -r1.4 drmmode_display.c
> > --- src/drmmode_display.c 5 Dec 2022 16:41:17 - 1.4
> > +++ src/drmmode_display.c 7 Sep 2023 15:20:36 -
> > @@ -197,7 +197,7 @@ drmmode_wait_vblank(xf86CrtcPtr crtc, dr
> > * version and DRM kernel module configuration, the vblank
> > * timestamp can either be in real time or monotonic time
> > */
> > -int drmmode_get_current_ust(int drm_fd, CARD64 * ust)
> > +int drmmode_get_current_ust(int drm_fd, uint64_t * ust)
> > {
> > uint64_t cap_value;
> > int ret;
> > @@ -211,14 +211,14 @@ int drmmode_get_current_ust(int drm_fd,
> > ret = clock_gettime(CLOCK_MONOTONIC, &now);
> > if (ret)
> > return ret;
> > - *ust = ((CARD64) now.tv_sec * 100) + ((CARD64) now.tv_nsec / 1000);
> > + *ust = ((uint64_t) now.tv_sec * 100) + ((uint64_t) now.tv_nsec /
> > 1000);
> > return 0;
> > }
> >
> > /*
> > * Get current frame count and frame count timestamp of the crtc.
> > */
> > -int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, CARD64 *ust, CARD64 *msc)
> > +int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, uint64_t *ust, uint64_t
> > *msc)
> > {
> > ScrnInfoPtr scrn = crtc->scrn;
> > uint32_t seq;
> > @@ -303,7 +303,7 @@ drmmode_do_crtc_dpms(xf86CrtcPtr crtc, i
> > drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
> > ScrnInfoPtr scrn = crtc->scrn;
> > AMDGPUEntPtr pAMDGPUEnt = AMDGPUEntPriv(scrn);
> > - CARD64 ust;
> > + uint64_t ust;
> > int ret;
> >
> > if (drmmode_crtc->d
Re: CVS: cvs.openbsd.org: xenocara
On Thu, Sep 07, 2023 at 05:24:56PM +0200, Matthieu Herrb wrote:
> On Thu, Sep 07, 2023 at 07:11:40AM +0200, Anton Lindqvist wrote:
> > On Wed, Sep 06, 2023 at 05:42:37AM -0600, Robert Nagy wrote:
> > > CVSROOT: /cvs
> > > Module name: xenocara
> > > Changes by: rob...@cvs.openbsd.org 2023/09/06 05:42:37
> > >
> > > Modified files:
> > > driver/xf86-video-amdgpu/src: amdgpu_present.c drmmode_display.h
> > > xserver/glamor : glamor.h glamor_egl.c
> > >
> > > Log message:
> > > unbreak build with clang-16 by fixing up function definitions to match
> > >
> > > our uint64_t is an unsinged long long, but CARD64 is defined as unsigned
> > > long
> > > so the function pointer types in both glamor and xf86-video-amdgpu were
> > > mismatched and clang-16 treats that as an error
> > >
> > > ok matthieu@
> >
> > This broke the tree. Here's a potential fix.
>
> Hmm no, this one reverts parts of the llvm 16 diffs.
>
> What about this that gets rid of CARD64 completely in this context ?
>
> hint for the X developpers: CARD64 and friends are normally reserved
> for the X protocol specification and implementation
>
> All other uses as cheap substites for uint64_t or similar are just
> historical artefacts from an era where there was no standard integer
> types with known fixed lengths.
This is still not enough.
I've deciced to cure the problem at its root.
Whith this patch, the tree builds with both base llvm and llvm 16 on
amd64. I've started a build i386 to double check 32 bit arches.
And it will allow to revert some other patches to reduce the number of
local changes. I also think that it has some chances to be accepted
upstreams.
basically just define the CARDnn types in terms on uint_nn everywhere.
Like for signal.h all systems still supported by X have stdint and the
uintnn_t types.
Index: proto/xorgproto/include/X11/Xmd.h
===
RCS file: /local/cvs/xenocara/proto/xorgproto/include/X11/Xmd.h,v
retrieving revision 1.2
diff -u -p -u -r1.2 Xmd.h
--- proto/xorgproto/include/X11/Xmd.h 11 Nov 2021 08:55:42 - 1.2
+++ proto/xorgproto/include/X11/Xmd.h 7 Sep 2023 16:20:01 -
@@ -57,6 +57,8 @@ SOFTWARE.
# include /* Solaris: defines _LP64 if necessary */
# endif
+#include
+
#if defined(__SIZEOF_LONG__)
# if __SIZEOF_LONG__ == 8
# define LONG64 /* 32/64-bit architecture */
@@ -107,15 +109,10 @@ typedef short INT16;
typedef signed charINT8;
-# ifdef LONG64
-typedef unsigned long CARD64;
-typedef unsigned int CARD32;
-# else
-typedef unsigned long long CARD64;
-typedef unsigned long CARD32;
-# endif
-typedef unsigned short CARD16;
-typedef unsigned char CARD8;
+typedef uint64_t CARD64;
+typedef uint32_t CARD32;
+typedef uint16_t CARD16;
+typedef uint8_t CARD8;
typedef CARD32 BITS32;
typedef CARD16 BITS16;
>
> Index: src/drmmode_display.c
> ===
> RCS file: /local/cvs/xenocara/driver/xf86-video-amdgpu/src/drmmode_display.c,v
> retrieving revision 1.4
> diff -u -p -u -r1.4 drmmode_display.c
> --- src/drmmode_display.c 5 Dec 2022 16:41:17 - 1.4
> +++ src/drmmode_display.c 7 Sep 2023 15:20:36 -
> @@ -197,7 +197,7 @@ drmmode_wait_vblank(xf86CrtcPtr crtc, dr
> * version and DRM kernel module configuration, the vblank
> * timestamp can either be in real time or monotonic time
> */
> -int drmmode_get_current_ust(int drm_fd, CARD64 * ust)
> +int drmmode_get_current_ust(int drm_fd, uint64_t * ust)
> {
> uint64_t cap_value;
> int ret;
> @@ -211,14 +211,14 @@ int drmmode_get_current_ust(int drm_fd,
> ret = clock_gettime(CLOCK_MONOTONIC, &now);
> if (ret)
> return ret;
> - *ust = ((CARD64) now.tv_sec * 100) + ((CARD64) now.tv_nsec / 1000);
> + *ust = ((uint64_t) now.tv_sec * 100) + ((uint64_t) now.tv_nsec /
> 1000);
> return 0;
> }
>
> /*
> * Get current frame count and frame count timestamp of the crtc.
> */
> -int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, CARD64 *ust, CARD64 *msc)
> +int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, uint64_t *ust, uint64_t *msc)
> {
> ScrnInfoPtr scrn = crtc->scrn;
> uint32_t seq;
> @@ -303,7 +303,7 @@ drmmode_do_crtc_dpms(xf86CrtcPtr crtc, i
> drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
> ScrnInfoPtr scrn = crtc->scrn;
> AMDGPUEntPtr pAMDGPUEnt = AMDGPUEntPriv(scrn);
> - CARD64 ust;
> + uint64_t ust;
> int ret;
>
> if (drmmode_crtc->dpms_mode == DPMSModeOn && mode != DPMSModeOn) {
> @@ -321,7 +321,7 @@ drmmode_do_crtc_dpms(xf86CrtcPtr crtc, i
> "%s cannot get last vblank counter\n",
> __func__);
> else {
> - CARD64 nominal_frame_rate, pix_in_frame;
> + uint64_t nominal_
Re: CVS: cvs.openbsd.org: xenocara
On Thu, Sep 07, 2023 at 05:24:35PM +0200, Matthieu Herrb wrote: > On Thu, Sep 07, 2023 at 07:11:40AM +0200, Anton Lindqvist wrote: > > On Wed, Sep 06, 2023 at 05:42:37AM -0600, Robert Nagy wrote: > > > CVSROOT: /cvs > > > Module name: xenocara > > > Changes by: rob...@cvs.openbsd.org 2023/09/06 05:42:37 > > > > > > Modified files: > > > driver/xf86-video-amdgpu/src: amdgpu_present.c drmmode_display.h > > > xserver/glamor : glamor.h glamor_egl.c > > > > > > Log message: > > > unbreak build with clang-16 by fixing up function definitions to match > > > > > > our uint64_t is an unsinged long long, but CARD64 is defined as unsigned > > > long > > > so the function pointer types in both glamor and xf86-video-amdgpu were > > > mismatched and clang-16 treats that as an error > > > > > > ok matthieu@ > > > > This broke the tree. Here's a potential fix. > > Hmm no, this one reverts parts of the llvm 16 diffs. > > What about this that gets rid of CARD64 completely in this context ? > > hint for the X developpers: CARD64 and friends are normally reserved > for the X protocol specification and implementation > > All other uses as cheap substites for uint64_t or similar are just > historical artefacts from an era where there was no standard integer > types with known fixed lengths. ok anton@ fwiw
Re: CVS: cvs.openbsd.org: xenocara
On Thu, Sep 07, 2023 at 07:11:40AM +0200, Anton Lindqvist wrote:
> On Wed, Sep 06, 2023 at 05:42:37AM -0600, Robert Nagy wrote:
> > CVSROOT:/cvs
> > Module name:xenocara
> > Changes by: rob...@cvs.openbsd.org 2023/09/06 05:42:37
> >
> > Modified files:
> > driver/xf86-video-amdgpu/src: amdgpu_present.c drmmode_display.h
> > xserver/glamor : glamor.h glamor_egl.c
> >
> > Log message:
> > unbreak build with clang-16 by fixing up function definitions to match
> >
> > our uint64_t is an unsinged long long, but CARD64 is defined as unsigned
> > long
> > so the function pointer types in both glamor and xf86-video-amdgpu were
> > mismatched and clang-16 treats that as an error
> >
> > ok matthieu@
>
> This broke the tree. Here's a potential fix.
Hmm no, this one reverts parts of the llvm 16 diffs.
What about this that gets rid of CARD64 completely in this context ?
hint for the X developpers: CARD64 and friends are normally reserved
for the X protocol specification and implementation
All other uses as cheap substites for uint64_t or similar are just
historical artefacts from an era where there was no standard integer
types with known fixed lengths.
Index: src/drmmode_display.c
===
RCS file: /local/cvs/xenocara/driver/xf86-video-amdgpu/src/drmmode_display.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 drmmode_display.c
--- src/drmmode_display.c 5 Dec 2022 16:41:17 - 1.4
+++ src/drmmode_display.c 7 Sep 2023 15:20:36 -
@@ -197,7 +197,7 @@ drmmode_wait_vblank(xf86CrtcPtr crtc, dr
* version and DRM kernel module configuration, the vblank
* timestamp can either be in real time or monotonic time
*/
-int drmmode_get_current_ust(int drm_fd, CARD64 * ust)
+int drmmode_get_current_ust(int drm_fd, uint64_t * ust)
{
uint64_t cap_value;
int ret;
@@ -211,14 +211,14 @@ int drmmode_get_current_ust(int drm_fd,
ret = clock_gettime(CLOCK_MONOTONIC, &now);
if (ret)
return ret;
- *ust = ((CARD64) now.tv_sec * 100) + ((CARD64) now.tv_nsec / 1000);
+ *ust = ((uint64_t) now.tv_sec * 100) + ((uint64_t) now.tv_nsec /
1000);
return 0;
}
/*
* Get current frame count and frame count timestamp of the crtc.
*/
-int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, CARD64 *ust, CARD64 *msc)
+int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, uint64_t *ust, uint64_t *msc)
{
ScrnInfoPtr scrn = crtc->scrn;
uint32_t seq;
@@ -303,7 +303,7 @@ drmmode_do_crtc_dpms(xf86CrtcPtr crtc, i
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
ScrnInfoPtr scrn = crtc->scrn;
AMDGPUEntPtr pAMDGPUEnt = AMDGPUEntPriv(scrn);
- CARD64 ust;
+ uint64_t ust;
int ret;
if (drmmode_crtc->dpms_mode == DPMSModeOn && mode != DPMSModeOn) {
@@ -321,7 +321,7 @@ drmmode_do_crtc_dpms(xf86CrtcPtr crtc, i
"%s cannot get last vblank counter\n",
__func__);
else {
- CARD64 nominal_frame_rate, pix_in_frame;
+ uint64_t nominal_frame_rate, pix_in_frame;
drmmode_crtc->dpms_last_ust = ust;
drmmode_crtc->dpms_last_seq = seq;
@@ -347,7 +347,7 @@ drmmode_do_crtc_dpms(xf86CrtcPtr crtc, i
xf86DrvMsg(scrn->scrnIndex, X_ERROR,
"%s cannot get current time\n", __func__);
else if (drmmode_crtc->dpms_last_ust) {
- CARD64 time_elapsed, delta_seq;
+ uint64_t time_elapsed, delta_seq;
time_elapsed = ust - drmmode_crtc->dpms_last_ust;
delta_seq = time_elapsed * drmmode_crtc->dpms_last_fps;
delta_seq /= 100;
Index: src/drmmode_display.h
===
RCS file: /local/cvs/xenocara/driver/xf86-video-amdgpu/src/drmmode_display.h,v
retrieving revision 1.5
diff -u -p -u -r1.5 drmmode_display.h
--- src/drmmode_display.h 6 Sep 2023 11:42:37 - 1.5
+++ src/drmmode_display.h 7 Sep 2023 15:20:36 -
@@ -127,7 +127,7 @@ typedef struct {
PixmapPtr prime_scanout_pixmap;
int dpms_mode;
- CARD64 dpms_last_ust;
+ uint64_t dpms_last_ust;
uint32_t dpms_last_seq;
int dpms_last_fps;
uint32_t interpolated_vblanks;
@@ -285,7 +285,7 @@ Bool amdgpu_do_pageflip(ScrnInfoPtr scrn
enum drmmode_flip_sync flip_sync,
uint32_t target_msc);
int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, uint64_t *ust, uint64_t *msc);
-int drmmode_get_current_ust(int drm_fd, CARD64 * ust);
+int drmmode_get_current_ust(int drm_fd, uint64_t * ust);
void drmmode_crtc_set_vrr(xf86CrtcPtr crtc, Bool enabled);
Bool drmmode_w
Re: CVS: cvs.openbsd.org: xenocara
On Wed, Sep 06, 2023 at 05:42:37AM -0600, Robert Nagy wrote:
> CVSROOT: /cvs
> Module name: xenocara
> Changes by: rob...@cvs.openbsd.org 2023/09/06 05:42:37
>
> Modified files:
> driver/xf86-video-amdgpu/src: amdgpu_present.c drmmode_display.h
> xserver/glamor : glamor.h glamor_egl.c
>
> Log message:
> unbreak build with clang-16 by fixing up function definitions to match
>
> our uint64_t is an unsinged long long, but CARD64 is defined as unsigned long
> so the function pointer types in both glamor and xf86-video-amdgpu were
> mismatched and clang-16 treats that as an error
>
> ok matthieu@
This broke the tree. Here's a potential fix.
Index: src/drmmode_display.c
===
RCS file: /cvs/xenocara/driver/xf86-video-amdgpu/src/drmmode_display.c,v
retrieving revision 1.4
diff -u -p -r1.4 drmmode_display.c
--- src/drmmode_display.c 5 Dec 2022 16:41:17 - 1.4
+++ src/drmmode_display.c 7 Sep 2023 04:49:05 -
@@ -161,7 +161,7 @@ drmmode_ConvertToKMode(ScrnInfoPtr scrn,
*/
Bool
drmmode_wait_vblank(xf86CrtcPtr crtc, drmVBlankSeqType type,
- uint32_t target_seq, unsigned long signal, uint64_t *ust,
+ uint32_t target_seq, unsigned long signal, CARD64 *ust,
uint32_t *result_seq)
{
int crtc_id = drmmode_get_crtc_id(crtc);
Index: src/drmmode_display.h
===
RCS file: /cvs/xenocara/driver/xf86-video-amdgpu/src/drmmode_display.h,v
retrieving revision 1.5
diff -u -p -r1.5 drmmode_display.h
--- src/drmmode_display.h 6 Sep 2023 11:42:37 - 1.5
+++ src/drmmode_display.h 7 Sep 2023 04:49:05 -
@@ -284,13 +284,13 @@ Bool amdgpu_do_pageflip(ScrnInfoPtr scrn
amdgpu_drm_abort_proc abort,
enum drmmode_flip_sync flip_sync,
uint32_t target_msc);
-int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, uint64_t *ust, uint64_t *msc);
+int drmmode_crtc_get_ust_msc(xf86CrtcPtr crtc, CARD64 *ust, CARD64 *msc);
int drmmode_get_current_ust(int drm_fd, CARD64 * ust);
void drmmode_crtc_set_vrr(xf86CrtcPtr crtc, Bool enabled);
Bool drmmode_wait_vblank(xf86CrtcPtr crtc, drmVBlankSeqType type,
uint32_t target_seq, unsigned long signal,
-uint64_t *ust, uint32_t *result_seq);
+CARD64 *ust, uint32_t *result_seq);
extern miPointerSpriteFuncRec drmmode_sprite_funcs;
Re: CVS: cvs.openbsd.org: xenocara
On Mon, May 08, 2023 at 09:35:25AM -0600, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2023/05/08 09:35:25 > > Modified files: > font/encodings : Makefile.am Makefile.in aclocal.m4 > > Log message: > Add ISO8859-14 encoding > > This allows legacy applications (xcalc for instance) to work without > the: "Warning: missing charsets in String to FontSet conversion" > message on systems with only ISO8859-1 and UTF-8 encoded fonts installed. > I believe this is missing a 'cvs add iso8859-14.enc'. ===> font/encodings exec /usr/bin/make install FCCACHE=: MKFONTDIR=: MKFONTSCALE=: Making install in large /bin/mkdir -p '/dest/xbase/usr/X11R6/lib/X11/fonts/encodings/large' /usr/bin/install -p -o root -g bin -m 644 big5.eten-0.enc.gz big5hkscs-0.enc.gz cns11643-1.enc.gz cns11643-2.enc.gz cns11643-3.enc.gz gb18030-0.enc.gz gb18030.2000-0.enc.gz gb18030.2000-1.enc.gz gb2312.1980-0.enc.gz gbk-0.enc.gz jisx0201.1976-0.enc.gz jisx0208.1990-0.enc.gz jisx0212.1990-0.enc.gz ksc5601.1987-0.enc.gz ksc5601.1992-3.enc.gz sun.unicode.india-0.enc.gz encodings.dir '/dest/xbase/usr/X11R6/lib/X11/fonts/encodings/large' /usr/bin/gzip -n -c < /usr/src/xenocara/font/encodings/iso8859-13.enc > iso8859-13.enc.gz make: don't know how to make iso8859-14.enc (prerequisite of: iso8859-14.enc.gz) Stop in xenocara/font/encodings/obj *** Error 1 in xenocara/font/encodings/obj (Makefile:420 'install-recursive': @fail= failcom='exit 1'; for f in x $MAKEFLAGS; do case $f i...) *** Error 2 in xenocara/font/encodings (../Makefile.inc:6 'realinstall') *** Error 2 in xenocara/font (:48 'realinstall': @for entry in encodings adobe-100dpi adobe-75dpi adobe-utopia-100dpi adobe-...) *** Error 2 in xenocara (:48 'realinstall': @for entry in proto font/util data/bitmaps lib app data xserver driver util doc ...) *** Error 2 in xenocara (Makefile:118 'release-install': @exec /usr/bin/make install)
Re: CVS: cvs.openbsd.org: xenocara
On Thu, Nov 10, 2022 at 11:19:23AM -0700, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2022/11/10 11:19:23 > > Modified files: > app/xterm : charproc.c menu.c > > Log message: > Prevent users from enabling allowFontOps by menu or via resources. > > This further protects from CVE-2022-2602 (although allowFontOps where > disabled by default in OpenBSD since 2009). > Oops, I mean CVE-2022-45063, sorry for the confusion. -- Matthieu Herrb
Re: CVS: cvs.openbsd.org: xenocara
On Sun, Nov 06, 2022 at 04:33:13AM -0700, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2022/11/06 04:33:13 > > Modified files: > lib/pixman/pixman: pixman-trap.c > > Log message: > CVE 2022-44638 An integer overflow in pixman mat lead to out-of-bounds > write. > ok tb@ -- Matthieu Herrb
Re: CVS: cvs.openbsd.org: xenocara
On 30/11/21 01:52 -0700, Robert Nagy wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: rob...@cvs.openbsd.org 2021/11/30 01:52:59 > > Modified files: > app/xrdb : Makefile.bsd-wrapper > > Log message: > switch away from using tradcpp(1) to cpp(1) > this was ok'd by matthieu@, but my editor did not let me finish
Re: CVS: cvs.openbsd.org: xenocara
On Thu, Nov 11, 2021 at 02:03:16AM -0700, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2021/11/11 02:03:16 > > Modified files: > xserver: ChangeLog Makefile.am Makefile.in README.md >configure configure.ac meson_options.txt >xorg-server.m4 > xserver/Xext : Makefile.in geext.c hashtable.c hashtable.h >saver.c shm.c vidmode.c xres.c xselinux_ext.c >xselinux_hooks.c xselinux_label.c xselinuxint.h >xtest.c xvmain.c > xserver/Xi : Makefile.in closedev.c exevents.c exglobals.h >extinit.c grabdev.c selectev.c >xichangehierarchy.h xipassivegrab.c >xiproperty.c xiquerydevice.c xiselectev.c > xserver/composite: Makefile.in compalloc.c compinit.c compint.h > compwindow.c > xserver/config : Makefile.in udev.c > xserver/damageext: Makefile.in damageext.c > xserver/dbe: Makefile.in dbe.c dbestruct.h > xserver/dix: Makefile.am Makefile.in colormap.c cursor.c >devices.c dispatch.c dixfonts.c enterleave.c >eventconvert.c events.c getevents.c globals.c >grabs.c inpututils.c main.c pixmap.c privates.c >property.c ptrveloc.c region.c resource.c >swaprep.c touch.c window.c > xserver/doc: Makefile.in Xserver-spec.xml > xserver/doc/dtrace: Makefile.in Xserver-DTrace.xml > xserver/dri3 : Makefile.am Makefile.in dri3.c dri3_priv.h >dri3_request.c dri3_screen.c > xserver/exa: Makefile.in exa.c exa.h exa_accel.c exa_mixed.c >exa_offscreen.c exa_priv.h exa_unaccel.c > xserver/fb : Makefile.in fbbltone.c fbcmap_mi.c fbpixmap.c > xserver/glamor : Makefile.in glamor.c glamor.h >glamor_composite_glyphs.c glamor_egl.c >glamor_fbo.c glamor_font.c glamor_gradient.c >glamor_largepixmap.c glamor_picture.c >glamor_pixmap.c glamor_priv.h glamor_program.c >glamor_rects.c glamor_render.c glamor_spans.c >glamor_transfer.c glamor_transfer.h >glamor_transform.c glamor_utils.h glamor_vbo.c >glamor_xv.c > xserver/glx: Makefile.in createcontext.c extension_string.c >extension_string.h glxcmds.c glxcontext.h >glxext.h indirect_dispatch_swap.c >indirect_util.c vndcmds.c > xserver/hw : Makefile.am Makefile.in > xserver/hw/kdrive: Makefile.in > xserver/hw/kdrive/ephyr: Makefile.in README ephyr.c ephyr.h >ephyr_glamor_glx.c ephyrinit.c >ephyrlog.h ephyrvideo.c hostx.c hostx.h > xserver/hw/kdrive/ephyr/man: Makefile.in > xserver/hw/kdrive/src: Makefile.am Makefile.in kdrive.c kinput.c > kxv.c > xserver/hw/vfb : InitInput.c InitOutput.c Makefile.am >Makefile.in > xserver/hw/vfb/man: Makefile.in > xserver/hw/xfree86: Makefile.am Makefile.in sdksyms.sh > xorg-wrapper.c xorgconf.cpp > xserver/hw/xfree86/common: Makefile.am Makefile.in compiler.h > dgaproc.h xf86.h xf86Bus.c xf86Bus.h > xf86Config.c xf86Configure.c > xf86Cursor.c xf86DGA.c xf86Events.c > xf86Globals.c xf86Helper.c xf86Init.c > xf86Mode.c xf86Module.h xf86Opt.h > xf86Option.c xf86Priv.h xf86Privstr.h > xf86VGAarbiter.c xf86Xinput.c > xf86Xinput.h xf86fbman.c xf86pciBus.c > xf86platformBus.c xf86str.h xf86xv.c > xisb.c > xserver/hw/xfree86/ddc: Makefile.in edid.h interpret_edid.c > print_edid.c > xserver/hw/xfree86/dixmods: Makefile.am Makefile.in > xserver/hw/xfree86/doc: Makefile.in README.modes Registry > ddxDesign.xml > xserver/hw/xfree86/dri: Makefile.in dri.c > xserver/hw/xfree86/dri2: Makefile.in dri2.c dri2.h dri2ext.c > xserver/hw/xfree86/dri2/pci_ids: Makefile.in i965_pci_ids.h >pci_id_driver_map.h > xserver/hw/xfree86/drivers: Makefile.am Makefile.in > xserver/hw/xfree86/drivers/modesetting: Makefile.in dri2.c >
Re: CVS: cvs.openbsd.org: xenocara
On 2021/09/06 09:44, Sebastien Marie wrote: > On Mon, Sep 06, 2021 at 09:38:04AM +0200, Matthieu Herrb wrote: > > On Mon, Sep 06, 2021 at 04:53:36PM +1000, Damien Miller wrote: > > > this breaks xterm on freshly-installed systems: > > > > > > keroppi$ env DISPLAY=:0 xterm > > > xterm: unveil > > > > > > from ktrace, it looks like it is failing when trying to unveil a > > > nonexistent directory: > > > > > > 93248 xtermNAMI "/home/djm/.cache/fontconfig" > > > 93248 xtermRET unveil -1 errno 2 No such file or directory > > > > > > Maybe it should stat/access the paths first? Or more stuff in skel? > > > > Either add .cache to skel or ignore ENOENT for dirs in home. > > > > I'm wondering if /usr/local/share/fonts/ is also going to be a problem > > and if I should extend the ENOENT checks for the system > > directories... > > The following are fine with base,xbase sets installed: > - /usr/X11R6 > - /var/cache/fontconfig > - etc_utmp > - etc_wtmp > > But the other might failed without ports installed: > - /usr/local/share/fonts > - /usr/local/share/icons > - /usr/local/lib/X11/icons Ths system directories could be added to base sets couldn't they?
Re: CVS: cvs.openbsd.org: xenocara
On Mon, Sep 06, 2021 at 09:38:04AM +0200, Matthieu Herrb wrote:
> On Mon, Sep 06, 2021 at 04:53:36PM +1000, Damien Miller wrote:
> > this breaks xterm on freshly-installed systems:
> >
> > keroppi$ env DISPLAY=:0 xterm
> > xterm: unveil
> >
> > from ktrace, it looks like it is failing when trying to unveil a
> > nonexistent directory:
> >
> > 93248 xtermNAMI "/home/djm/.cache/fontconfig"
> > 93248 xtermRET unveil -1 errno 2 No such file or directory
> >
> > Maybe it should stat/access the paths first? Or more stuff in skel?
>
> Either add .cache to skel or ignore ENOENT for dirs in home.
>
> I'm wondering if /usr/local/share/fonts/ is also going to be a problem
> and if I should extend the ENOENT checks for the system
> directories...
The following are fine with base,xbase sets installed:
- /usr/X11R6
- /var/cache/fontconfig
- etc_utmp
- etc_wtmp
But the other might failed without ports installed:
- /usr/local/share/fonts
- /usr/local/share/icons
- /usr/local/lib/X11/icons
> Index: main.c
> ===
> RCS file: /cvs/OpenBSD/xenocara/app/xterm/main.c,v
> retrieving revision 1.50
> diff -u -p -u -r1.50 main.c
> --- main.c2 Sep 2021 09:31:38 - 1.50
> +++ main.c6 Sep 2021 07:37:42 -
> @@ -2910,18 +2910,18 @@ main(int argc, char *argv[]ENVP_ARG)
> char homefile[PATH_MAX];
>
> snprintf(homefile, sizeof homefile, "%s/.fonts", env);
> -if (unveil(homefile, "r") == -1) {
> +if (unveil(homefile, "r") == -1 && errno != ENOENT) {
> xtermWarning("unveil\n");
> exit(1);
> }
> snprintf(homefile, sizeof homefile, "%s/.cache/fontconfig",
> env);
> -if (unveil(homefile, "r") == -1) {
> +if (unveil(homefile, "r") == -1 && errno != ENOENT) {
> xtermWarning("unveil\n");
> exit(1);
> }
> snprintf(homefile, sizeof homefile, "%s/.icons", env);
> -if (unveil(homefile, "r") == -1) {
> +if (unveil(homefile, "r") == -1 && errno != ENOENT) {
> xtermWarning("unveil\n");
> exit(1);
> }
> @@ -2930,12 +2930,12 @@ main(int argc, char *argv[]ENVP_ARG)
> char xdgfile[PATH_MAX];
>
> snprintf(xdgfile, sizeof xdgfile, "%s/fontconfig", env);
> -if (unveil(xdgfile, "r") == -1) {
> +if (unveil(xdgfile, "r") == -1 && errno != ENOENT) {
> xtermWarning("unveil\n");
> exit(1);
> }
> snprintf(xdgfile, sizeof xdgfile, "%s/icons", env);
> -if (unveil(xdgfile, "r") == -1) {
> +if (unveil(xdgfile, "r") == -1 && errno != ENOENT) {
> xtermWarning("unveil\n");
> exit(1);
> }
> @@ -2944,12 +2944,12 @@ main(int argc, char *argv[]ENVP_ARG)
> char xdgfile[PATH_MAX];
>
> snprintf(xdgfile, sizeof xdgfile, "%s/fontconfig", env);
> -if (unveil(xdgfile, "r") == -1) {
> +if (unveil(xdgfile, "r") == -1 && errno != ENOENT) {
> xtermWarning("unveil\n");
> exit(1);
> }
> snprintf(xdgfile, sizeof xdgfile, "%s/icons", env);
> -if (unveil(xdgfile, "r") == -1) {
> +if (unveil(xdgfile, "r") == -1 && errno != ENOENT) {
> xtermWarning("unveil\n");
> exit(1);
> }
> @@ -2958,7 +2958,7 @@ main(int argc, char *argv[]ENVP_ARG)
> char xdgfile[PATH_MAX];
>
> snprintf(xdgfile, sizeof xdgfile, "%s/fontconfig", env);
> -if (unveil(xdgfile, "r") == -1) {
> +if (unveil(xdgfile, "r") == -1 && errno != ENOENT) {
> xtermWarning("unveil\n");
> exit(1);
> }
>
> >
> > On Thu, 2 Sep 2021, Theo de Raadt wrote:
> >
> > > hurray
> > >
> > > Matthieu Herrb wrote:
> > >
> > > > CVSROOT:/cvs
> > > > Module name:xenocara
> > > > Changes by: matth...@cvs.openbsd.org2021/09/02 03:31:38
> > > >
> > > > Modified files:
> > > > app/xterm : main.c
> > > >
> > > > Log message:
> > > > Unveil paths needed by xterm at run-time. work with tb@ and deraadt@
> > > >
> > > > Only in (default) case where there are no exec-formatted or
> > > > exec-selected resources set. In those case the commands and their
> > > > arguments could be anywhere.
> > > >
> > >
> > >
>
> --
> Matthieu Herrb
>
--
Sebastien Marie
Re: CVS: cvs.openbsd.org: xenocara
On Mon, Sep 06, 2021 at 04:53:36PM +1000, Damien Miller wrote:
> this breaks xterm on freshly-installed systems:
>
> keroppi$ env DISPLAY=:0 xterm
> xterm: unveil
>
> from ktrace, it looks like it is failing when trying to unveil a
> nonexistent directory:
>
> 93248 xtermNAMI "/home/djm/.cache/fontconfig"
> 93248 xtermRET unveil -1 errno 2 No such file or directory
>
> Maybe it should stat/access the paths first? Or more stuff in skel?
Either add .cache to skel or ignore ENOENT for dirs in home.
I'm wondering if /usr/local/share/fonts/ is also going to be a problem
and if I should extend the ENOENT checks for the system
directories...
Index: main.c
===
RCS file: /cvs/OpenBSD/xenocara/app/xterm/main.c,v
retrieving revision 1.50
diff -u -p -u -r1.50 main.c
--- main.c 2 Sep 2021 09:31:38 - 1.50
+++ main.c 6 Sep 2021 07:37:42 -
@@ -2910,18 +2910,18 @@ main(int argc, char *argv[]ENVP_ARG)
char homefile[PATH_MAX];
snprintf(homefile, sizeof homefile, "%s/.fonts", env);
-if (unveil(homefile, "r") == -1) {
+if (unveil(homefile, "r") == -1 && errno != ENOENT) {
xtermWarning("unveil\n");
exit(1);
}
snprintf(homefile, sizeof homefile, "%s/.cache/fontconfig",
env);
-if (unveil(homefile, "r") == -1) {
+if (unveil(homefile, "r") == -1 && errno != ENOENT) {
xtermWarning("unveil\n");
exit(1);
}
snprintf(homefile, sizeof homefile, "%s/.icons", env);
-if (unveil(homefile, "r") == -1) {
+if (unveil(homefile, "r") == -1 && errno != ENOENT) {
xtermWarning("unveil\n");
exit(1);
}
@@ -2930,12 +2930,12 @@ main(int argc, char *argv[]ENVP_ARG)
char xdgfile[PATH_MAX];
snprintf(xdgfile, sizeof xdgfile, "%s/fontconfig", env);
-if (unveil(xdgfile, "r") == -1) {
+if (unveil(xdgfile, "r") == -1 && errno != ENOENT) {
xtermWarning("unveil\n");
exit(1);
}
snprintf(xdgfile, sizeof xdgfile, "%s/icons", env);
-if (unveil(xdgfile, "r") == -1) {
+if (unveil(xdgfile, "r") == -1 && errno != ENOENT) {
xtermWarning("unveil\n");
exit(1);
}
@@ -2944,12 +2944,12 @@ main(int argc, char *argv[]ENVP_ARG)
char xdgfile[PATH_MAX];
snprintf(xdgfile, sizeof xdgfile, "%s/fontconfig", env);
-if (unveil(xdgfile, "r") == -1) {
+if (unveil(xdgfile, "r") == -1 && errno != ENOENT) {
xtermWarning("unveil\n");
exit(1);
}
snprintf(xdgfile, sizeof xdgfile, "%s/icons", env);
-if (unveil(xdgfile, "r") == -1) {
+if (unveil(xdgfile, "r") == -1 && errno != ENOENT) {
xtermWarning("unveil\n");
exit(1);
}
@@ -2958,7 +2958,7 @@ main(int argc, char *argv[]ENVP_ARG)
char xdgfile[PATH_MAX];
snprintf(xdgfile, sizeof xdgfile, "%s/fontconfig", env);
-if (unveil(xdgfile, "r") == -1) {
+if (unveil(xdgfile, "r") == -1 && errno != ENOENT) {
xtermWarning("unveil\n");
exit(1);
}
>
> On Thu, 2 Sep 2021, Theo de Raadt wrote:
>
> > hurray
> >
> > Matthieu Herrb wrote:
> >
> > > CVSROOT: /cvs
> > > Module name: xenocara
> > > Changes by: matth...@cvs.openbsd.org2021/09/02 03:31:38
> > >
> > > Modified files:
> > > app/xterm : main.c
> > >
> > > Log message:
> > > Unveil paths needed by xterm at run-time. work with tb@ and deraadt@
> > >
> > > Only in (default) case where there are no exec-formatted or
> > > exec-selected resources set. In those case the commands and their
> > > arguments could be anywhere.
> > >
> >
> >
--
Matthieu Herrb
Re: CVS: cvs.openbsd.org: xenocara
this breaks xterm on freshly-installed systems: keroppi$ env DISPLAY=:0 xterm xterm: unveil from ktrace, it looks like it is failing when trying to unveil a nonexistent directory: 93248 xtermNAMI "/home/djm/.cache/fontconfig" 93248 xtermRET unveil -1 errno 2 No such file or directory Maybe it should stat/access the paths first? Or more stuff in skel? On Thu, 2 Sep 2021, Theo de Raadt wrote: > hurray > > Matthieu Herrb wrote: > > > CVSROOT:/cvs > > Module name:xenocara > > Changes by: matth...@cvs.openbsd.org2021/09/02 03:31:38 > > > > Modified files: > > app/xterm : main.c > > > > Log message: > > Unveil paths needed by xterm at run-time. work with tb@ and deraadt@ > > > > Only in (default) case where there are no exec-formatted or > > exec-selected resources set. In those case the commands and their > > arguments could be anywhere. > > > >
Re: CVS: cvs.openbsd.org: xenocara
hurray Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2021/09/02 03:31:38 > > Modified files: > app/xterm : main.c > > Log message: > Unveil paths needed by xterm at run-time. work with tb@ and deraadt@ > > Only in (default) case where there are no exec-formatted or > exec-selected resources set. In those case the commands and their > arguments could be anywhere. >
Re: CVS: cvs.openbsd.org: xenocara
On Sat, Nov 28, 2020 at 07:39:49AM -0700, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2020/11/28 07:39:49 > > > Log message: > Update to libX11 1.7.0. Tested by gkoehler@ and jsg@ I forgot tb@ sorry. -- Matthieu Herrb
Re: CVS: cvs.openbsd.org: xenocara
On Tue, Sep 22, 2020 at 12:14:43AM -0600, Jonathan Gray wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: j...@cvs.openbsd.org2020/09/22 00:14:43 > > Modified files: > lib/mesa/src/compiler/spirv: vtn_opencl.c > > Log message: > spirv/opencl: Cast opcode up front to avoid warnings > > >From Kristian Hoegsberg > b40281d8306367e68dde6b723d2114d9cb5fca5a in mainline Mesa above is the cherry-picked hash, should have been 0bc516fceb742e4c1ce2d47f129d19d8bb005d13
Re: CVS: cvs.openbsd.org: xenocara
I had a startx setup, which broke. When I switched to xenodm, it works fine, plus it needed moving the ~/.xinitrc + ~/.xsession files away. Can somebody please add an entry to current.html in the FAQ? Thanks On Thu, Oct 25, 2018 at 4:56 PM Theo de Raadt wrote: > > CVSROOT:/cvs > Module name:xenocara > Changes by: dera...@cvs.openbsd.org 2018/10/25 15:55:18 > > Modified files: > xserver: Makefile.bsd-wrapper > > Log message: > Disable setuid on the X server. We have always known it is a trash fire > and we held out hope too long. This will break some stuff. Let's start > with non-setuid as the baseline, and see if it is worth trying to fix > the broken parts in some other way. >
Re: CVS: cvs.openbsd.org: xenocara
The dri3proto and libxshmfence imports where discussed with kettenis@ and jsg@. They will be enabled soon, once a few missing bits have been committed. Thanks to Mark for the process-shared futex patch that makes it possible to eventually switch to DRI3 in Xorg/Mesa. -- Matthieu Herrb
freetype bumps [Re: CVS: cvs.openbsd.org: xenocara]
On 2018/05/25 10:35, Matthieu Herrb wrote: > On Fri, May 25, 2018 at 08:45:44AM +0100, Stuart Henderson wrote: > > The usual problem with packages occurred. > > Hi, > > Can you give an example ? I still don't understand why this would be > needed. We don't do that for libs like libm or other base system > libs, as normally we keep track of inter-libraries dependencies almost > everywhere. And as I understand it, newer ld will enforce that even > more. > > From my experience, this is only a problem for packages with missing > wantlib declarations. I did rebuild all the packages I'm using after > the bump, and did'nt run in any issue for which I would blame missing > another lib bump. > > I may be wrong, but I'd like to understand. > > > > > Next time, please give the same type of shlib_version bump to the > > other libraries in xenocara that depend on libfreetype, thanks! > > Some packages depend on freetype AND another X lib that depends on freetype, Until new packages are available and the user has run pkg_add -u, this results in two conflicting versions of freetype being pulled in. WANTLIB is not the problem. WANTLIBs are correct. The packages do get updated once new packages are available, the problem is in the interim between bumping libs and new packages becoming available. Build times: aarch64 ~4 days amd64 1 day arm ~10 days hppa~4 days i38628-50 hours mips64 4 days mips64el6 weeks powerpc ~2..3 weeks sparc64 ~2..3 weeks But unless bulk builders know that they need to restart builds, the previous build needs to finish before the new one can start, so it can be double those times before packages built against new libs are shipped. I don't know what the case is with libc/libm. We *do* do this type of bump in libssl/libcrypto/libtls because we know things break otherwise. And there is a clear problem with the freetype chain because it keeps happening again and again. By bumping the other libs e.g. fontconfig, already-installed software will continue to use the version of the other libs already on their disk, which uses the old freetype, avoiding the conflict. - Forwarded message from Stuart Henderson - From: Stuart Henderson Date: Thu, 26 May 2016 15:03:09 +0100 To: David Coppa Cc: dera...@openbsd.org, Christian Weisgerber , ajacou...@openbsd.org, Matthieu Herrb User-Agent: Mutt/1.6.1 (2016-04-27) Subject: Re: Fwd: [UPDATE] freetype-2.6.3 On 2016/05/26 15:44, David Coppa wrote: > On Thu, May 26, 2016 at 2:12 PM, Stuart Henderson > wrote: > > On 2016/05/26 11:57, Stuart Henderson wrote: > >> On 2016/05/26 12:47, Christian Weisgerber wrote: > >> > David Coppa: > >> > > >> > > Here's an update to the latest freetype release. > >> > > Please put it in a bulk build. > >> > > >> > FYI, I'm running an amd64 bulk build with this. > >> > > >> > -- > >> > Christian "naddy" Weisgerber na...@mips.inka.de > >> > >> There were no freetype-related problems on i386 (just some > >> stupid random java-looking breakage in libreoffice, I'm > >> reattempting the libreoffice build now just to make sure > >> there's nothing hidden in there).. > >> > > > > Built this time. OK with me. > > This commit will bump libfreetype to 25.0 from 24.1. > > Since I do not want to repeat the mess that happened on 2015-06 when > we went from 23.0 to 24.0, is there something particular I should do? > Do we need to coordinate in some ways? > > Ciao! > David Ah yes. Looking back at icb logs 2015-06 was two problems. One was that people didn't know the update was coming. The other was that some libraries in X depend on freetype. Therefore when someone used an old package that itself uses freetype *and* pulls in an X library (say Xft) that also depends on freetype, there's a conflict. somepackage | | | ` libXft || |` new libfreetype | `- old libfreetype What you could do to avoid it is also bump the libs that depend on freetype. Which I think is libXft and libXfont. Then an existing package will pull in the *old* Xft and old freetype, so it won't see the new Xft/freetype until new packages are ready. - End forwarded message - - Forwarded message from Stuart Henderson - From: Stuart Henderson Date: Fri, 13 Jan 2017 16:35:34 + To: David Coppa Cc: Matthieu Herrb , Matthieu Herrb , na...@openbsd.org User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: FreeType 2.7.1 On 2017/01/13 17:14, David Coppa wrote: > On Fri, Jan 13, 2017 at 11:18 AM, Matthieu Herrb wrote: > > On Thu, Jan 12, 2017 at 02:17:02PM +0100, David Coppa wrote: > >> On Thu, Jan 12, 2017 at 1:46 PM, Stuart Henderson > >> wrote: > >> > On 2017/01/09 15:29, David Coppa wrote: > >> >> Here's the update to freetype-2.7.1, both inline and as attachment. > >> > > >> >> As usual, please test it. > >> >> > >> >> And, i
Re: CVS: cvs.openbsd.org: xenocara
On Fri, May 25, 2018 at 08:45:44AM +0100, Stuart Henderson wrote: > The usual problem with packages occurred. Hi, Can you give an example ? I still don't understand why this would be needed. We don't do that for libs like libm or other base system libs, as normally we keep track of inter-libraries dependencies almost everywhere. And as I understand it, newer ld will enforce that even more. >From my experience, this is only a problem for packages with missing wantlib declarations. I did rebuild all the packages I'm using after the bump, and did'nt run in any issue for which I would blame missing another lib bump. I may be wrong, but I'd like to understand. > > Next time, please give the same type of shlib_version bump to the > other libraries in xenocara that depend on libfreetype, thanks! > -- Matthieu Herrb pgpjvEMiChoUi.pgp Description: PGP signature
Re: CVS: cvs.openbsd.org: xenocara
The usual problem with packages occurred. Next time, please give the same type of shlib_version bump to the other libraries in xenocara that depend on libfreetype, thanks! On 2018/05/21 05:52, David Coppa wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: dco...@cvs.openbsd.org 2018/05/21 05:52:27 > > Modified files: > lib/freetype : CMakeLists.txt ChangeLog ChangeLog.20 >ChangeLog.21 ChangeLog.22 ChangeLog.23 >ChangeLog.24 ChangeLog.25 ChangeLog.26 Jamfile >Jamrules Makefile README README.git autogen.sh >configure modules.cfg shlib_version >vms_make.com > lib/freetype/builds: detect.mk exports.mk freetype.mk >link_dos.mk link_std.mk modules.mk >toplevel.mk > lib/freetype/builds/amiga: README makefile makefile.os4 > smakefile > lib/freetype/builds/amiga/include/config: ftconfig.h ftmodule.h > lib/freetype/builds/amiga/src/base: ftdebug.c ftsystem.c > lib/freetype/builds/ansi: ansi-def.mk ansi.mk > lib/freetype/builds/beos: beos-def.mk beos.mk detect.mk > lib/freetype/builds/cmake: FindHarfBuzz.cmake iOS.cmake > testbuild.sh > lib/freetype/builds/compiler: ansi-cc.mk bcc-dev.mk bcc.mk > emx.mk gcc-dev.mk gcc.mk intelc.mk > unix-lcc.mk visualage.mk > visualc.mk watcom.mk win-lcc.mk > lib/freetype/builds/dos: detect.mk dos-def.mk dos-emx.mk >dos-gcc.mk dos-wat.mk > lib/freetype/builds/mac: FreeType.m68k_cfm.make.txt >FreeType.m68k_far.make.txt >FreeType.ppc_carbon.make.txt >FreeType.ppc_classic.make.txt ftmac.c > lib/freetype/builds/os2: detect.mk os2-def.mk os2-dev.mk >os2-gcc.mk > lib/freetype/builds/symbian: bld.inf freetype.mmp > lib/freetype/builds/unix: config.guess config.sub configure > configure.ac configure.raw detect.mk > freetype-config.in freetype2.in > freetype2.m4 ft-munmap.m4 ftconfig.h > ftconfig.in ftsystem.c install.mk > unix-cc.in unix-def.in unix-dev.mk > unix-lcc.mk unix.mk unixddef.mk > lib/freetype/builds/vms: ftconfig.h ftsystem.c > lib/freetype/builds/wince: ftdebug.c > lib/freetype/builds/wince/vc2005-ce: freetype.vcproj index.html > lib/freetype/builds/wince/vc2008-ce: freetype.vcproj index.html > lib/freetype/builds/windows: detect.mk ftdebug.c w32-bcc.mk >w32-bccd.mk w32-dev.mk w32-gcc.mk >w32-icc.mk w32-intl.mk w32-lcc.mk >w32-mingw32.mk w32-vcc.mk >w32-wat.mk win32-def.mk > lib/freetype/builds/windows/vc2005: freetype.vcproj index.html > lib/freetype/builds/windows/vc2008: freetype.vcproj index.html > lib/freetype/builds/windows/vc2010: freetype.sln > freetype.vcxproj > freetype.vcxproj.filters > index.html > lib/freetype/builds/windows/visualc: freetype.dsp >freetype.vcproj index.html > lib/freetype/builds/windows/visualce: freetype.dsp > freetype.vcproj index.html > lib/freetype/devel: ft2build.h ftoption.h > lib/freetype/docs: CHANGES CUSTOMIZE DEBUG FTL.TXT INSTALL > INSTALL.ANY INSTALL.CROSS INSTALL.GNU > INSTALL.UNIX INSTALL.VMS MAKEPP TODO > VERSIONS.TXT formats.txt freetype-config.1 > raster.txt release > lib/freetype/docs/reference: ft2-auto_hinter.html >ft2-base_interface.html >ft2-basic_types.html >ft2-bdf_fonts.html >ft2-bitmap_handling.html >ft2-bzip2.html >ft2-cache_subsystem.html >ft2-cff_driver.html >ft2-cid_fonts.html >ft2-computations.html >ft2-error_code_values.html >ft2-error_e
Re: CVS: cvs.openbsd.org: xenocara
here nowadays Jonathan, apologies for not writing this long. Lost mum & dad in India, so was kinda' busy sorting personal things out. My old facebook ID went funny on me so got me a new one @ www.facebook.com/rajneesh.shetty.754 @DisQus & Wordpress.. https://disqus.com/by/rajneesh_shetty/ www.vishagotra.wordpress.com cheers, Rajneesh N. Shetty On Wed, 21/2/18, Jonathan Gray wrote: Subject: CVS: cvs.openbsd.org: xenocara To: source-changes@openbsd.org Received: Wednesday, 21 February, 2018, 2:01 PM CVSROOT:   /cvs Module name:   xenocara Changes by:   j...@cvs.openbsd.org   2018/02/20 23:01:53 Modified files:    lib/libdrm  : Makefile.bsd-wrapper    lib/mesa   : Makefile.bsd-wrapper Log message: No need to override PTHREADSTUBS_CFLAGS/PTHREADSTUBS_LIBS anymore as the configure scripts have been changed to avoid pthread-stubs.
Re: CVS: cvs.openbsd.org: xenocara
On Tue 2018.01.02 at 07:04 -0700, Okan Demirmen wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: o...@cvs.openbsd.org2018/01/02 07:04:58 > > Modified files: > app/cwm: calmwm.c > > Log message: > Only exec the fallback when in CWM_EXEC_WM state. > > Broken quit noticed by Ve Telko. anton@ came up with the same diff but I got it too late - thanks!
Re: CVS: cvs.openbsd.org: xenocara
On Tue 2017.12.19 at 07:30 -0700, Okan Demirmen wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: o...@cvs.openbsd.org2017/12/19 07:30:53 > > Modified files: > app/cwm: calmwm.h client.c conf.c xutil.c > > Log message: > Add support for _NET_WM_STATE_SKIP_PAGER and _NET_WM_STATE_SKIP_TASKBAR; > eerily > close to cwm's 'ignore'. > > Roughly based on an initial diff from Walter Alejandro Iglesias, but with > support for both Atoms and without cwm-based bindings. Sorry, this was based on a diff by Erling Westenvik...
Re: CVS: cvs.openbsd.org: xenocara
On Sun, Jan 22, 2017 at 09:09:18PM +, Stuart Henderson wrote: > On 2017/01/21 11:40, Matthieu Herrb wrote: > > CVSROOT:/cvs > > Module name:xenocara > > Changes by: matth...@cvs.openbsd.org2017/01/21 11:40:20 > > > > Modified files: > > driver/xf86-input-vmmouse: ChangeLog Makefile.in config.h.in > >configure configure.ac > > driver/xf86-input-vmmouse/fdi: Makefile.in > > driver/xf86-input-vmmouse/man: Makefile.in > > driver/xf86-input-vmmouse/shared: Makefile.in vmmouse_client.c > > vmmouse_client.h > > vmmouse_defs.h vmmouse_proto.c > > vmmouse_proto.h > > driver/xf86-input-vmmouse/src: Makefile.am Makefile.in vmmouse.c > > driver/xf86-input-vmmouse/tools: Makefile.am Makefile.in > > vmmouse_detect.c > > Added files: > > driver/xf86-input-vmmouse/tools: vmmouse_iopl.c vmmouse_udev.c > > > > Log message: > > Update to xf86-input-vmmouse 13.1.0 > > > > I see this if I check xenocara sets now: > > cd /var/sets; cksum -a sha256 x*tgz > SHA256 > 6070a6071 > > ./usr/X11R6/lib/modules/input/vmmouse_drv.a > 6072d6072 > < ./usr/X11R6/lib/modules/input/vmmouse_drv.so > > Is this expected? No. I committed from the wrong tree where I had only disabled the code that causes that for amd64. Fixed now on i386 too. Thanks for the notice. -- Matthieu Herrb [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: CVS: cvs.openbsd.org: xenocara
On 2017/01/21 11:40, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2017/01/21 11:40:20 > > Modified files: > driver/xf86-input-vmmouse: ChangeLog Makefile.in config.h.in > configure configure.ac > driver/xf86-input-vmmouse/fdi: Makefile.in > driver/xf86-input-vmmouse/man: Makefile.in > driver/xf86-input-vmmouse/shared: Makefile.in vmmouse_client.c > vmmouse_client.h > vmmouse_defs.h vmmouse_proto.c > vmmouse_proto.h > driver/xf86-input-vmmouse/src: Makefile.am Makefile.in vmmouse.c > driver/xf86-input-vmmouse/tools: Makefile.am Makefile.in >vmmouse_detect.c > Added files: > driver/xf86-input-vmmouse/tools: vmmouse_iopl.c vmmouse_udev.c > > Log message: > Update to xf86-input-vmmouse 13.1.0 > I see this if I check xenocara sets now: cd /var/sets; cksum -a sha256 x*tgz > SHA256 6070a6071 > ./usr/X11R6/lib/modules/input/vmmouse_drv.a 6072d6072 < ./usr/X11R6/lib/modules/input/vmmouse_drv.so Is this expected?
Re: CVS: cvs.openbsd.org: xenocara
On Sun, Oct 09, 2016 at 03:54:56AM -0600, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2016/10/09 03:54:56 > > Modified files: > data/xkeyboard-config: Makefile.inc > > Log message: > Provide a default clean target now that bsd.subdir.mk doesn't. That was tested and ok nigel@. -- Matthieu Herrb [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: CVS: cvs.openbsd.org: xenocara
On Fri 2016.09.30 at 11:38 -0400, Bryan Steele wrote: > On Fri, Sep 30, 2016 at 09:12:19AM -0600, Okan Demirmen wrote: > > CVSROOT:/cvs > > Module name:xenocara > > Changes by: o...@cvs.openbsd.org2016/09/30 09:12:19 > > > > Modified files: > > app/cwm: calmwm.h menu.c mousefunc.c > > > > Log message: > > Replace mousefunc_sweep_draw() with a generic menu_windraw() using va > > lists; use it appropriately for both window dimension and position in > > the respective mousefunc calls. > > > > ok bryent@ > > ok brynet@ too! ;-) oops, sorry!!
Re: CVS: cvs.openbsd.org: xenocara
On Fri, Sep 30, 2016 at 09:12:19AM -0600, Okan Demirmen wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: o...@cvs.openbsd.org2016/09/30 09:12:19 > > Modified files: > app/cwm: calmwm.h menu.c mousefunc.c > > Log message: > Replace mousefunc_sweep_draw() with a generic menu_windraw() using va > lists; use it appropriately for both window dimension and position in > the respective mousefunc calls. > > ok bryent@ ok brynet@ too! ;-)
Re: CVS: cvs.openbsd.org: xenocara
Jeremie Courreges-Anglas writes: > CVSROOT: /cvs > Module name: xenocara > Changes by: j...@cvs.openbsd.org2016/09/16 14:29:03 > > Modified files: > app/video : video.c > > Log message: > Make video -i work ootb. > > video(1) uses mmap and ioctls by default, those ioctls only work on > video(4) devices. If -i is passed, use read(2) instead of the mmap(2) > routines, instead of requiring the user to pass also pass the -g flag. oops, I forgot to add: the patch was from Gregor Best. Thanks! -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: CVS: cvs.openbsd.org: xenocara
On Mon, Jun 06, 2016 at 01:31:22PM -0600, Marcus Glocker wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: mgloc...@cvs.openbsd.org2016/06/06 13:31:22 > > Modified files: > app/video : video.c > > Log message: > Comparing maximum frame buffer size after VIDIOC_DQBUF ioctl against > 'buf.bytesused' instead of 'buf.length' makes more sense. > > From Patrick Keshish It's Patrick Keshishian of course. Sorry my bad and thanks sthen@ for pointing out.
Re: CVS: cvs.openbsd.org: xenocara
On Sun, May 29, 2016 at 05:59:59AM -0600, David Coppa wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: dco...@cvs.openbsd.org 2016/05/29 05:59:59 > > Modified files: > lib/fontconfig/src: shlib_version > lib/libXfont : Makefile.bsd-wrapper > lib/libXft : Makefile.bsd-wrapper > > Log message: > Bump following freetype update. > > Suggested by sthen@ > > ok sthen@, naddy@, matthieu@ Ahem, it seems you missed the bump for libfreetype itself. -- Matthieu Herrb [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: CVS: cvs.openbsd.org: xenocara
On Wed, Apr 20, 2016 at 06:23:56AM -0600, Mark Kettenis wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: kette...@cvs.openbsd.org2016/04/20 06:23:56 > > Modified files: > lib/mesa/src/egl/drivers/dri2: platform_x11.c > > Log message: > Make sure we authenticate before calling loader_get_driver_for_fd(). This > function invokes some drm ioctls that require the client to be authenticated. > > tested by espie@ > ok jsg@ More precisely, this fixed some weird messages I got when running a video player like mpv (which defaults to opengl), both on radeon and intel. In case somebody else wants to run more tests.
Re: CVS: cvs.openbsd.org: xenocara
On Fri, Dec 25, 2015 at 02:02:20PM -0500, Michael McConville wrote: > Jonathan Gray wrote: > > On Wed, Dec 23, 2015 at 03:09:14PM -0500, Michael McConville wrote: > > > Jonathan Gray wrote: > > > > CVSROOT:/cvs > > > > Module name:xenocara > > > > Changes by: j...@cvs.openbsd.org2015/12/23 07:28:32 > > > > > > > > Modified files: > > > > . : README > > > > > > > > Log message: > > > > Remove the llvm section, the ports llvm is too outdated for Mesa now. > > > > The version of g++ in base can't handle the headers of recent llvm > > > > either and the common xenocara makefiles will need a way to optionally > > > > look for llvm/libelf in /usr/local if XENOCARA_BUILD_GALLIUM == "llvm" > > > > > > Pascal's had a working 3.7.0 port for months now. It hasn't been > > > committed because it breaks xulrunner (some atomics issue) and we're all > > > slacking on fixing it. > > > > [...] > > (cmake seems busted for some reason with gcc 4.9) > > [...] > > Have you tried since the recent update? > The problem was cmake complained about invalid files when linking llvm. Even though the autoconf build system for llvm is deprecated I opted for that in the end over trying to figure it out as the failure occurred after a few hours of building llvm when linking ar files into a binary. Given I haven't seen that when building other projects with cmake it seems to be a problem with llvm.
Re: CVS: cvs.openbsd.org: xenocara
Jonathan Gray wrote: > On Wed, Dec 23, 2015 at 03:09:14PM -0500, Michael McConville wrote: > > Jonathan Gray wrote: > > > CVSROOT: /cvs > > > Module name: xenocara > > > Changes by: j...@cvs.openbsd.org2015/12/23 07:28:32 > > > > > > Modified files: > > > . : README > > > > > > Log message: > > > Remove the llvm section, the ports llvm is too outdated for Mesa now. > > > The version of g++ in base can't handle the headers of recent llvm > > > either and the common xenocara makefiles will need a way to optionally > > > look for llvm/libelf in /usr/local if XENOCARA_BUILD_GALLIUM == "llvm" > > > > Pascal's had a working 3.7.0 port for months now. It hasn't been > > committed because it breaks xulrunner (some atomics issue) and we're all > > slacking on fixing it. > > [...] > (cmake seems busted for some reason with gcc 4.9) > [...] Have you tried since the recent update?
Re: CVS: cvs.openbsd.org: xenocara
On Wed, Dec 23, 2015 at 03:09:14PM -0500, Michael McConville wrote: > Jonathan Gray wrote: > > CVSROOT:/cvs > > Module name:xenocara > > Changes by: j...@cvs.openbsd.org2015/12/23 07:28:32 > > > > Modified files: > > . : README > > > > Log message: > > Remove the llvm section, the ports llvm is too outdated for Mesa now. > > The version of g++ in base can't handle the headers of recent llvm > > either and the common xenocara makefiles will need a way to optionally > > look for llvm/libelf in /usr/local if XENOCARA_BUILD_GALLIUM == "llvm" > > Pascal's had a working 3.7.0 port for months now. It hasn't been > committed because it breaks xulrunner (some atomics issue) and we're all > slacking on fixing it. As I mented on ports@ a while back llvm with that update can't handle the llvm headers provided by the port itself, so the only way I managed to build radeonsi lately is to build llvm svn via autoconf (cmake seems busted for some reason) with gcc 4.9, then build Mesa with gcc 4.9. This exposed a series of bugs with Mesa and pixman where the sse tests optimised out the sse instructions, which is now fixed in Mesa 11.0.8. https://bugs.freedesktop.org/show_bug.cgi?id=91806
Re: CVS: cvs.openbsd.org: xenocara
Jonathan Gray wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: j...@cvs.openbsd.org2015/12/23 07:28:32 > > Modified files: > . : README > > Log message: > Remove the llvm section, the ports llvm is too outdated for Mesa now. > The version of g++ in base can't handle the headers of recent llvm > either and the common xenocara makefiles will need a way to optionally > look for llvm/libelf in /usr/local if XENOCARA_BUILD_GALLIUM == "llvm" Pascal's had a working 3.7.0 port for months now. It hasn't been committed because it breaks xulrunner (some atomics issue) and we're all slacking on fixing it.
Re: CVS: cvs.openbsd.org: xenocara
On Sun, Oct 25, 2015 at 08:58:43AM +0100, Matthieu Herrb wrote: > On Sat, Oct 24, 2015 at 06:20:35AM +0200, Antoine Jacoutot wrote: > > On Fri, Oct 23, 2015 at 06:29:31AM -0600, Christian Weisgerber wrote: > > > CVSROOT: /cvs > > > Module name: xenocara > > > Changes by: na...@cvs.openbsd.org 2015/10/23 06:29:31 > > > > > > Modified files: > > > lib/fontconfig/conf.d: Makefile > > > > > > Log message: > > > Don't enable 10-autohint.conf by default. It causes problems with > > > xterm -fa mono (underscores disappearing because the glyph exceeds > > > the cell size), matthieu@ can't remember why he enabled it, and it's > > > not enabled by default anywhere else. ok matthieu@ > > > > This made my current fonts really hard to read... > > > > I don't think we should change the fontconfig defaults to match some > developpers personnal tastes. I've been plagued by this disappearing underscore for ages. I don't give a fuck what's the default in Xorg, nor how many centuries it takes for this to get fixed upstream, but if this change means I no longer have to figure out whether or not I'm going to be able to see underscores in my code (which, btw is CRIPPLING for my development environment), I'm all for it. It's not developer's personal preferences. Not seeing underscores in an xterm because you chose the wrong size is a BUG, plain and simple. If it can't be properly fixed (by say, ensuring the font SHOWS underscores in each and every size), then I'm fine with the next best thing, which is a work-around. THANK YOU naddy@.
Re: CVS: cvs.openbsd.org: xenocara
Antoine Jacoutot wrote: > > > This made my current fonts really hard to read... > > > > > > > I don't think we should change the fontconfig defaults to match some > > developpers personnal tastes. > > I never said we should :-) > I only mentionned this because I can bet some people will ask|complain why > their fonts in 5.9 are ugly -- that's all. > > > Fonts appearance are a lot a matter of personal preferences. So it's > > ok to need to tweak some buttons if you're not happy with the defaults. > > Sure, and that's what I do. > > > What application(s) is(are) affected ? > > At least, all gtk3 apps. > > > Which font and font size is it ? > > Small(er) fonts; size 8 and below. > > > Personnally I do indeed prefer autohinting for small DejaVu Mono > > fonts. So I've set that in my ~/.config/fontconfig/fonts.conf file: > > Yeah, I use something similar. > I know how to work with that stuff; I am just saying that this small commit > does have a real obvious effect on the display. > Maybe we should enable the autohinter only for such small fonts? The default did it always? Certainly it was screwing up size 16 or so fonts. Can we make a new file 10-small-autohint like Matthieu has for a new default?
Re: CVS: cvs.openbsd.org: xenocara
>On Sat, Oct 24, 2015 at 06:20:35AM +0200, Antoine Jacoutot wrote: >> On Fri, Oct 23, 2015 at 06:29:31AM -0600, Christian Weisgerber wrote: >> > CVSROOT: /cvs >> > Module name: xenocara >> > Changes by:na...@cvs.openbsd.org 2015/10/23 06:29:31 >> > >> > Modified files: >> >lib/fontconfig/conf.d: Makefile >> > >> > Log message: >> > Don't enable 10-autohint.conf by default. It causes problems with >> > xterm -fa mono (underscores disappearing because the glyph exceeds >> > the cell size), matthieu@ can't remember why he enabled it, and it's >> > not enabled by default anywhere else. ok matthieu@ >> >> This made my current fonts really hard to read... >> > >I don't think we should change the fontconfig defaults to match some >developpers personnal tastes. > >Fonts appearance are a lot a matter of personal preferences. So it's >ok to need to tweak some buttons if you're not happy with the defaults. And yet... every operating system shipping with X has changed these default from the default shipped in upstream, or switched to display managers that completely hide that default. >What application(s) is(are) affected ? >Which font and font size is it ? > >Personnally I do indeed prefer autohinting for small DejaVu Mono >fonts. So I've set that in my ~/.config/fontconfig/fonts.conf file: > > > > >DejaVu Sans Mono > > >true > > Just brutal. So unfriendly to everyone. Can make a really good guess about which year that was invented.
Re: CVS: cvs.openbsd.org: xenocara
> > This made my current fonts really hard to read... > > > > I don't think we should change the fontconfig defaults to match some > developpers personnal tastes. I never said we should :-) I only mentionned this because I can bet some people will ask|complain why their fonts in 5.9 are ugly -- that's all. > Fonts appearance are a lot a matter of personal preferences. So it's > ok to need to tweak some buttons if you're not happy with the defaults. Sure, and that's what I do. > What application(s) is(are) affected ? At least, all gtk3 apps. > Which font and font size is it ? Small(er) fonts; size 8 and below. > Personnally I do indeed prefer autohinting for small DejaVu Mono > fonts. So I've set that in my ~/.config/fontconfig/fonts.conf file: Yeah, I use something similar. I know how to work with that stuff; I am just saying that this small commit does have a real obvious effect on the display. -- Antoine
Re: CVS: cvs.openbsd.org: xenocara
On Sat, Oct 24, 2015 at 06:20:35AM +0200, Antoine Jacoutot wrote: > On Fri, Oct 23, 2015 at 06:29:31AM -0600, Christian Weisgerber wrote: > > CVSROOT:/cvs > > Module name:xenocara > > Changes by: na...@cvs.openbsd.org 2015/10/23 06:29:31 > > > > Modified files: > > lib/fontconfig/conf.d: Makefile > > > > Log message: > > Don't enable 10-autohint.conf by default. It causes problems with > > xterm -fa mono (underscores disappearing because the glyph exceeds > > the cell size), matthieu@ can't remember why he enabled it, and it's > > not enabled by default anywhere else. ok matthieu@ > > This made my current fonts really hard to read... > I don't think we should change the fontconfig defaults to match some developpers personnal tastes. Fonts appearance are a lot a matter of personal preferences. So it's ok to need to tweak some buttons if you're not happy with the defaults. What application(s) is(are) affected ? Which font and font size is it ? Personnally I do indeed prefer autohinting for small DejaVu Mono fonts. So I've set that in my ~/.config/fontconfig/fonts.conf file: DejaVu Sans Mono true -- Matthieu Herrb [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: CVS: cvs.openbsd.org: xenocara
On Fri, Oct 23, 2015 at 06:29:31AM -0600, Christian Weisgerber wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: na...@cvs.openbsd.org 2015/10/23 06:29:31 > > Modified files: > lib/fontconfig/conf.d: Makefile > > Log message: > Don't enable 10-autohint.conf by default. It causes problems with > xterm -fa mono (underscores disappearing because the glyph exceeds > the cell size), matthieu@ can't remember why he enabled it, and it's > not enabled by default anywhere else. ok matthieu@ This made my current fonts really hard to read... -- Antoine
Re: CVS: cvs.openbsd.org: xenocara
On 06/19/14 20:38, Nick Holland wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: n...@cvs.openbsd.org2014/06/19 18:38:54 > > Modified files: > lib/libXtst/man: XTestCompareCurrentCursorWithWindow.man >XTestCompareCursorWithWindow.man >XTestDiscard.man XTestFakeButtonEvent.man >XTestFakeKeyEvent.man XTestFakeMotionEvent.man >XTestFakeRelativeMotionEvent.man >XTestGrabControl.man XTestSetGContextOfGC.man >XTestSetVisualIDOfVisual.man > > Log message: > fix for man pages -- per roff(7), .so should be based in the parent man > page directory. fixes the following X man 3 pages: > XTestCompareCurrentCursorWithWindow.man > XTestCompareCursorWithWindow.man XTestDiscard.man > XTestFakeButtonEvent.man XTestFakeKeyEvent.man > XTestFakeMotionEvent.man XTestFakeRelativeMotionEvent.man > XTestGrabControl.man XTestSetGContextOfGC.man > XTestSetVisualIDOfVisual.man that was ok schwarze@
Re: CVS: cvs.openbsd.org: xenocara
On Mon, Apr 21, 2014 at 8:52 AM, Okan Demirmen wrote: > CVSROOT:/cvs > Module name:xenocara > Changes by: o...@cvs.openbsd.org2014/04/21 06:52:14 > > Modified files: > app/cwm: conf.c > > Log message: > plug memleak (currently unused func); from Tiago Cunha oops, actually it is a function in use...
Re: CVS: cvs.openbsd.org: xenocara
On Sat, Aug 17, 2013 at 11:05, Brian Callahan wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: bcal...@cvs.openbsd.org 2013/08/17 11:05:43 > > Modified files: > share/mk : bsd.xconf.mk > > Log message: > As discussed with matthieu@, since there are no octeon machines with video > output where OpenGL makes since, we should disable OpenGL on octeon. > ok matthieu@ Does this mean no opengl clients? They should still work when forwarded to a remote server, no?
Re: CVS: cvs.openbsd.org: xenocara
Christian Weisgerber wrote: > Log message: > Update to luit 1.1.1. ok matthieu@ I forgot to say that this, together with the local change to sys.c, has fixed luit's tty handling after the introduction of the UNIX98 PTY functions. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: CVS: cvs.openbsd.org: xenocara
On 01/25/13 17:33, Brad Smith wrote: CVSROOT:/cvs Module name:xenocara Changes by: b...@cvs.openbsd.org2013/01/25 15:33:54 Modified files: app/xsystrace : callbacks.c Log message: Rename dprintf function to debugprintf so as to not conflict with POSIX function name. ok millert@ and matthieu@ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: CVS: cvs.openbsd.org: xenocara
On 2013/01/09 22:09, Okan Demirmen wrote: > this should solve it, but I'm not able to test until tomorrow: > and if not, I'll revert. yay :) that fixes it, thanks. OK sthen.
Re: CVS: cvs.openbsd.org: xenocara
On Thu 2013.01.10 at 02:43 +, Stuart Henderson wrote: > On 2013/01/01 07:19, Okan Demirmen wrote: > > CVSROOT:/cvs > > Module name:xenocara > > Changes by: o...@cvs.openbsd.org2013/01/01 07:19:56 > > > > Modified files: > > app/cwm: calmwm.h client.c group.c kbfunc.c xutil.c > > > > Log message: > > make num of groups no longer off-by-one; from Alexander Polakov > > > > note that a re-exec of cwm will not rewrite the group number atom of > > *existing* clients, so they will remain off-by-one until each client has > > its atom updated, or of course a restart of X. > > > > Does this actually fix something, or is it just cosmetic? > It breaks my use of cwm. doh, and it's only cosmetic - sorry. > Before this commit, when cwm started (and before carrying out any > group operations), newly opened windows would be in group1 / > _NET_WM_DESKTOP(CARDINAL) = 0, the initial root window is > _NET_CURRENT_DESKTOP(CARDINAL) = 0, and when you do 'grouponly2' > followed by 'grouponly1' those same windows are displayed. > > After this commit, we get the same atoms for root/client windows > on the initial display, but 'grouponly2' followed by 'grouponly1' > goes to _NET_CURRENT_DESKTOP(CARDINAL) = 1, and the only way to > re-display the desktop0 windows is to use cyclegroup/rcyclegroup. this should solve it, but I'm not able to test until tomorrow: and if not, I'll revert. Index: group.c === RCS file: /home/open/cvs/xenocara/app/cwm/group.c,v retrieving revision 1.68 diff -u -p -r1.68 group.c --- group.c 1 Jan 2013 14:50:01 - 1.68 +++ group.c 10 Jan 2013 03:05:19 - @@ -160,7 +160,7 @@ group_init(struct screen_ctx *sc) xu_ewmh_net_showing_desktop(sc); xu_ewmh_net_virtual_roots(sc); - group_setactive(sc, 0); + group_setactive(sc, 1); } void
Re: CVS: cvs.openbsd.org: xenocara
On 2013/01/01 07:19, Okan Demirmen wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: o...@cvs.openbsd.org2013/01/01 07:19:56 > > Modified files: > app/cwm: calmwm.h client.c group.c kbfunc.c xutil.c > > Log message: > make num of groups no longer off-by-one; from Alexander Polakov > > note that a re-exec of cwm will not rewrite the group number atom of > *existing* clients, so they will remain off-by-one until each client has > its atom updated, or of course a restart of X. > Does this actually fix something, or is it just cosmetic? It breaks my use of cwm. Trimmed config:- -- -- -- -- -- sticky yes bind XF86Back rcyclegroup bind XF86Forward cyclegroup # alt- switch to virtual desktop bind M-1grouponly1 bind M-2grouponly2 bind M-3grouponly3 bind M-4grouponly4 bind M-5grouponly5 bind M-6grouponly6 bind M-7grouponly7 bind M-8grouponly8 bind M-9grouponly9 # alt-shift- move current window to virtual desktop bind MS-1 movetogroup1 bind MS-2 movetogroup2 bind MS-3 movetogroup3 bind MS-4 movetogroup4 bind MS-5 movetogroup5 bind MS-6 movetogroup6 bind MS-7 movetogroup7 bind MS-8 movetogroup8 bind MS-9 movetogroup9 -- -- -- -- -- Before this commit, when cwm started (and before carrying out any group operations), newly opened windows would be in group1 / _NET_WM_DESKTOP(CARDINAL) = 0, the initial root window is _NET_CURRENT_DESKTOP(CARDINAL) = 0, and when you do 'grouponly2' followed by 'grouponly1' those same windows are displayed. After this commit, we get the same atoms for root/client windows on the initial display, but 'grouponly2' followed by 'grouponly1' goes to _NET_CURRENT_DESKTOP(CARDINAL) = 1, and the only way to re-display the desktop0 windows is to use cyclegroup/rcyclegroup.
Re: CVS: cvs.openbsd.org: xenocara
On Fri, Jan 04, 2013 at 09:40:19AM -0700, Matthieu Herrb wrote: > Update to xterm 287. tested by mpi@ and krw@. And shadchin@, whose message arrived just while I was waiting for the commit to finish... -- Matthieu Herrb
Re: CVS: cvs.openbsd.org: xenocara
On Mon, Oct 29, 2012 at 03:19:16PM -0600, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2012/10/29 15:19:16 > > Modified files: > . : Makefile > > Log message: > Unlink share/pciids from the build. The generated file is not > used by xserver anymore. Any reason to not just tedu it completely ?
Re: CVS: cvs.openbsd.org: xenocara
On Wed, 04 Jul 2012 20:00:57 +0200, Okan Demirmen wrote: > On Wed 2012.07.04 at 18:46 +0200, Tim van der Molen wrote: > > On Tue, 03 Jul 2012 15:49:03 +0200, Okan Demirmen wrote: > > > CVSROOT: /cvs > > > Module name: xenocara > > > Changes by: o...@cvs.openbsd.org2012/07/03 07:49:03 > > > > > > Modified files: > > > app/cwm: calmwm.h client.c group.c screen.c xevents.c > > >xutil.c > > > > > > Log message: > > > re-implement atom handing; makes for a normalized and more consistent > > > separation between cwm and ewmh. seen by a few. > > > > This commit causes CM-x to terminate an entire application instead of > > closing only one of its windows. > > > > For example, attempting to close the preferences window of Firefox with > > CM-x results in Firefox terminating with the message: > > > > firefox: Fatal IO error 35 (Resource temporarily unavailable) on X server > > :0. > > > > Another example: pressing CM-x on a feh window: > > > > XIO: fatal IO error 0 (Undefined error: 0) on X server ":0" > > after 42 requests (42 known processed) with 0 events remaining. > > Thanks for the report; fix committed. Works beautifully; thanks.
Re: CVS: cvs.openbsd.org: xenocara
On Wed 2012.07.04 at 18:46 +0200, Tim van der Molen wrote: > On Tue, 03 Jul 2012 15:49:03 +0200, Okan Demirmen wrote: > > CVSROOT:/cvs > > Module name:xenocara > > Changes by: o...@cvs.openbsd.org2012/07/03 07:49:03 > > > > Modified files: > > app/cwm: calmwm.h client.c group.c screen.c xevents.c > > xutil.c > > > > Log message: > > re-implement atom handing; makes for a normalized and more consistent > > separation between cwm and ewmh. seen by a few. > > This commit causes CM-x to terminate an entire application instead of > closing only one of its windows. > > For example, attempting to close the preferences window of Firefox with > CM-x results in Firefox terminating with the message: > > firefox: Fatal IO error 35 (Resource temporarily unavailable) on X server :0. > > Another example: pressing CM-x on a feh window: > > XIO: fatal IO error 0 (Undefined error: 0) on X server ":0" > after 42 requests (42 known processed) with 0 events remaining. Thanks for the report; fix committed. Cheers, Okan
Re: CVS: cvs.openbsd.org: xenocara
On Tue, 03 Jul 2012 15:49:03 +0200, Okan Demirmen wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: o...@cvs.openbsd.org2012/07/03 07:49:03 > > Modified files: > app/cwm: calmwm.h client.c group.c screen.c xevents.c >xutil.c > > Log message: > re-implement atom handing; makes for a normalized and more consistent > separation between cwm and ewmh. seen by a few. This commit causes CM-x to terminate an entire application instead of closing only one of its windows. For example, attempting to close the preferences window of Firefox with CM-x results in Firefox terminating with the message: firefox: Fatal IO error 35 (Resource temporarily unavailable) on X server :0. Another example: pressing CM-x on a feh window: XIO: fatal IO error 0 (Undefined error: 0) on X server ":0" after 42 requests (42 known processed) with 0 events remaining. Regards, Tim
Re: CVS: cvs.openbsd.org: xenocara
Great, thanks. I was just composing a mail asking if you needed more testing. Glad to see this.in. Thanks Ian
Re: CVS: cvs.openbsd.org: xenocara
>> > CVSROOT:/cvs >> > Module name:xenocara >> > Changes by: shadc...@cvs.openbsd.org2011/10/16 11:18:58 >> > >> > Modified files: >> > data/xkeyboard-config: Makefile Makefile.inc >> > data/xkeyboard-config/rules: Makefile >> > dist/xkeyboard-config: Makefile.am Makefile.in NEWS aclocal.m4 >> >configure configure.in >> >xkeyboard-config.spec >> > dist/xkeyboard-config/compat: Makefile.in xfree86 >> > dist/xkeyboard-config/docs: Makefile.in >> > dist/xkeyboard-config/geometry: Makefile.in >> > dist/xkeyboard-config/geometry/digital_vndr: Makefile.in >> > dist/xkeyboard-config/geometry/sgi_vndr: Makefile.in >> > dist/xkeyboard-config/keycodes: Makefile.in >> > dist/xkeyboard-config/keycodes/digital_vndr: Makefile.in >> > dist/xkeyboard-config/keycodes/sgi_vndr: Makefile.in >> > dist/xkeyboard-config/keymap: Makefile.in >> > dist/xkeyboard-config/keymap/digital_vndr: Makefile.in >> > dist/xkeyboard-config/keymap/sgi_vndr: Makefile.in >> > dist/xkeyboard-config/keymap/sun_vndr: Makefile.in >> > dist/xkeyboard-config/po: bg.po ca.po da.po de.po eo.po es.po >> > fr.po hu.po ja.po nl.po pl.po ru.po >> > sl.po uk.po zh_CN.po >> > dist/xkeyboard-config/rules: Makefile.in base.extras.xml.in >> > base.o_s.part base.xml.in >> > evdev.extras.xml.in evdev.xml.in >> > xkb.dtd >> > dist/xkeyboard-config/rules/bin: Makefile.in >> > dist/xkeyboard-config/rules/compat: Makefile.in >> > variantsMapping.lst >> > dist/xkeyboard-config/semantics: Makefile.in >> > dist/xkeyboard-config/symbols: Makefile.in cm ctrl cz de ee in >> >jp keypad lk lv ma pc ru >> >srvr_ctrl symbols.dir terminate >> > dist/xkeyboard-config/symbols/digital_vndr: Makefile.in >> > dist/xkeyboard-config/symbols/fujitsu_vndr: Makefile.in >> > dist/xkeyboard-config/symbols/hp_vndr: Makefile.in >> > dist/xkeyboard-config/symbols/macintosh_vndr: Makefile.in >> > dist/xkeyboard-config/symbols/nec_vndr: Makefile.in >> > dist/xkeyboard-config/symbols/nokia_vndr: Makefile.in >> > dist/xkeyboard-config/symbols/sgi_vndr: Makefile.in >> > dist/xkeyboard-config/symbols/sony_vndr: Makefile.in >> > dist/xkeyboard-config/symbols/sun_vndr: Makefile.in us >> > dist/xkeyboard-config/symbols/xfree68_vndr: Makefile.in >> > dist/xkeyboard-config/types: Makefile.in pc >> > Added files: >> > data/xkeyboard-config/man: Makefile xkeyboard-config.7 >> > dist/xkeyboard-config: config.guess config.sub >> > dist/xkeyboard-config/man: Makefile.am Makefile.in man.xsl >> > >> > Log message: >> > Update to 2.4.1 >> > >> > ok jasper@, matthieu@ >> >> Since this update, in xdm my PS/2 and USB keyboards make the pc speaker >> beep for any key pressed, and no characters appear on screen. >> They still work fine in the console. >> Backing out this update fixes the problem. > > For the record, Matthieu pointed out how to fix it without a backout: > > "Clean obj dir and move /usr/X11R6/share/X11/xkb on the side before > re-running make build in data/xkeyboard-config." this fixed it for me. I usually newfs the /usr/X11R6 partition. I ran make obj && make build in that folder afterwards... thanks for the note!
Re: CVS: cvs.openbsd.org: xenocara
On Mon, Oct 17, 2011 at 09:38:03AM +0200, Stefan Sperling wrote: > On Sun, Oct 16, 2011 at 11:18:58AM -0600, Alexandr Shadchin wrote: > > CVSROOT:/cvs > > Module name:xenocara > > Changes by: shadc...@cvs.openbsd.org2011/10/16 11:18:58 > > > > Modified files: > > data/xkeyboard-config: Makefile Makefile.inc > > data/xkeyboard-config/rules: Makefile > > dist/xkeyboard-config: Makefile.am Makefile.in NEWS aclocal.m4 > >configure configure.in > >xkeyboard-config.spec > > dist/xkeyboard-config/compat: Makefile.in xfree86 > > dist/xkeyboard-config/docs: Makefile.in > > dist/xkeyboard-config/geometry: Makefile.in > > dist/xkeyboard-config/geometry/digital_vndr: Makefile.in > > dist/xkeyboard-config/geometry/sgi_vndr: Makefile.in > > dist/xkeyboard-config/keycodes: Makefile.in > > dist/xkeyboard-config/keycodes/digital_vndr: Makefile.in > > dist/xkeyboard-config/keycodes/sgi_vndr: Makefile.in > > dist/xkeyboard-config/keymap: Makefile.in > > dist/xkeyboard-config/keymap/digital_vndr: Makefile.in > > dist/xkeyboard-config/keymap/sgi_vndr: Makefile.in > > dist/xkeyboard-config/keymap/sun_vndr: Makefile.in > > dist/xkeyboard-config/po: bg.po ca.po da.po de.po eo.po es.po > > fr.po hu.po ja.po nl.po pl.po ru.po > > sl.po uk.po zh_CN.po > > dist/xkeyboard-config/rules: Makefile.in base.extras.xml.in > > base.o_s.part base.xml.in > > evdev.extras.xml.in evdev.xml.in > > xkb.dtd > > dist/xkeyboard-config/rules/bin: Makefile.in > > dist/xkeyboard-config/rules/compat: Makefile.in > > variantsMapping.lst > > dist/xkeyboard-config/semantics: Makefile.in > > dist/xkeyboard-config/symbols: Makefile.in cm ctrl cz de ee in > >jp keypad lk lv ma pc ru > >srvr_ctrl symbols.dir terminate > > dist/xkeyboard-config/symbols/digital_vndr: Makefile.in > > dist/xkeyboard-config/symbols/fujitsu_vndr: Makefile.in > > dist/xkeyboard-config/symbols/hp_vndr: Makefile.in > > dist/xkeyboard-config/symbols/macintosh_vndr: Makefile.in > > dist/xkeyboard-config/symbols/nec_vndr: Makefile.in > > dist/xkeyboard-config/symbols/nokia_vndr: Makefile.in > > dist/xkeyboard-config/symbols/sgi_vndr: Makefile.in > > dist/xkeyboard-config/symbols/sony_vndr: Makefile.in > > dist/xkeyboard-config/symbols/sun_vndr: Makefile.in us > > dist/xkeyboard-config/symbols/xfree68_vndr: Makefile.in > > dist/xkeyboard-config/types: Makefile.in pc > > Added files: > > data/xkeyboard-config/man: Makefile xkeyboard-config.7 > > dist/xkeyboard-config: config.guess config.sub > > dist/xkeyboard-config/man: Makefile.am Makefile.in man.xsl > > > > Log message: > > Update to 2.4.1 > > > > ok jasper@, matthieu@ > > Since this update, in xdm my PS/2 and USB keyboards make the pc speaker > beep for any key pressed, and no characters appear on screen. > They still work fine in the console. > Backing out this update fixes the problem. For the record, Matthieu pointed out how to fix it without a backout: "Clean obj dir and move /usr/X11R6/share/X11/xkb on the side before re-running make build in data/xkeyboard-config."
Re: CVS: cvs.openbsd.org: xenocara
On Sun, Oct 16, 2011 at 11:18:58AM -0600, Alexandr Shadchin wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: shadc...@cvs.openbsd.org2011/10/16 11:18:58 > > Modified files: > data/xkeyboard-config: Makefile Makefile.inc > data/xkeyboard-config/rules: Makefile > dist/xkeyboard-config: Makefile.am Makefile.in NEWS aclocal.m4 > configure configure.in > xkeyboard-config.spec > dist/xkeyboard-config/compat: Makefile.in xfree86 > dist/xkeyboard-config/docs: Makefile.in > dist/xkeyboard-config/geometry: Makefile.in > dist/xkeyboard-config/geometry/digital_vndr: Makefile.in > dist/xkeyboard-config/geometry/sgi_vndr: Makefile.in > dist/xkeyboard-config/keycodes: Makefile.in > dist/xkeyboard-config/keycodes/digital_vndr: Makefile.in > dist/xkeyboard-config/keycodes/sgi_vndr: Makefile.in > dist/xkeyboard-config/keymap: Makefile.in > dist/xkeyboard-config/keymap/digital_vndr: Makefile.in > dist/xkeyboard-config/keymap/sgi_vndr: Makefile.in > dist/xkeyboard-config/keymap/sun_vndr: Makefile.in > dist/xkeyboard-config/po: bg.po ca.po da.po de.po eo.po es.po > fr.po hu.po ja.po nl.po pl.po ru.po > sl.po uk.po zh_CN.po > dist/xkeyboard-config/rules: Makefile.in base.extras.xml.in >base.o_s.part base.xml.in >evdev.extras.xml.in evdev.xml.in >xkb.dtd > dist/xkeyboard-config/rules/bin: Makefile.in > dist/xkeyboard-config/rules/compat: Makefile.in > variantsMapping.lst > dist/xkeyboard-config/semantics: Makefile.in > dist/xkeyboard-config/symbols: Makefile.in cm ctrl cz de ee in > jp keypad lk lv ma pc ru > srvr_ctrl symbols.dir terminate > dist/xkeyboard-config/symbols/digital_vndr: Makefile.in > dist/xkeyboard-config/symbols/fujitsu_vndr: Makefile.in > dist/xkeyboard-config/symbols/hp_vndr: Makefile.in > dist/xkeyboard-config/symbols/macintosh_vndr: Makefile.in > dist/xkeyboard-config/symbols/nec_vndr: Makefile.in > dist/xkeyboard-config/symbols/nokia_vndr: Makefile.in > dist/xkeyboard-config/symbols/sgi_vndr: Makefile.in > dist/xkeyboard-config/symbols/sony_vndr: Makefile.in > dist/xkeyboard-config/symbols/sun_vndr: Makefile.in us > dist/xkeyboard-config/symbols/xfree68_vndr: Makefile.in > dist/xkeyboard-config/types: Makefile.in pc > Added files: > data/xkeyboard-config/man: Makefile xkeyboard-config.7 > dist/xkeyboard-config: config.guess config.sub > dist/xkeyboard-config/man: Makefile.am Makefile.in man.xsl > > Log message: > Update to 2.4.1 > > ok jasper@, matthieu@ Since this update, in xdm my PS/2 and USB keyboards make the pc speaker beep for any key pressed, and no characters appear on screen. They still work fine in the console. Backing out this update fixes the problem. pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 ukbd0 at uhidev0: 8 modifier keys, 6 key codes wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev1 at uhub2 port 3 configuration 1 interface 0 "Logitech USB-PS/2 Optical Mouse" rev 2.00/27.20 addr 4 uhidev1: iclass 3/1 [280902.373] (II) config/wscons: checking input device /dev/wskbd [280902.374] (II) wskbd: using layout us [280902.374] (II) LoadModule: "kbd" [280902.376] (II) Loading /usr/X11R6/lib/modules/input/kbd_drv.so [280902.376] (II) Module kbd: vendor="X.Org Foundation" [280902.376]compiled for 1.9.5, module version = 1.6.0 [280902.376]Module class: X.Org XInput Driver [280902.376]ABI class: X.Org XInput driver, version 11.0 [280902.376] (**) /dev/wskbd: always reports core events [280902.376] (**) Option "Protocol" "standard" [280902.376] (**) Option "XkbRules" "base" [280902.376] (**) Option "XkbModel" "pc105" [280902.376] (**) Option "XkbLayout" "us" [280902.376] (II) XINPUT: Adding extended input device "/dev/wskbd" (type: KEYBOARD)
Re: CVS: cvs.openbsd.org: xenocara
wrote: > CVSROOT:/cvs > Module name:xenocara > Changes by: matth...@cvs.openbsd.org2011/08/21 03:11:07 > > Modified files: >driver/xf86-input-keyboard/src: kbd.c > > Log message: > Fix initial xkb_options setting. Restores Ctrl+Alt+Backspace behaviour. > Strange that no one reported it beeing broken. I did report it a month ago, alongwith the /dev/wsmouse0 not configured which you fixed yesterday! thanks for the fixes!
Re: CVS: cvs.openbsd.org: xenocara
On Sun 2011.05.15 at 11:58 -0600, Okan Demirmen wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: o...@cvs.openbsd.org2011/05/15 11:58:47 > > Modified files: > app/cwm: calmwm.h > > Log message: > fix botched client and group cycle defines; noticed by Thomas Pfaff. > > "no cookie! fix it" - oga@ and a "please commit" sthen@
Re: CVS: cvs.openbsd.org: xenocara
On 04/17/11 16:16, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2011/04/17 09:16:24 > > Modified files: > lib/libXfixes : ChangeLog Makefile.bsd-wrapper aclocal.m4 >configure configure.ac > lib/libXfixes/include/X11/extensions: Xfixes.h > lib/libXfixes/src: Cursor.c Xfixesint.h > Removed files: > lib/libXfixes : INSTALL > > Log message: > Update to libXfixes 5.0 > > Hi, libXfixes was updated to version 5.1, the distribution files for creating a release haven't been updated to match the version change. distrib/sets/lists/xbase/md.amd64 etc. Regards Nigel Taylor
Re: CVS: cvs.openbsd.org: xenocara
On Sat, Jan 22, 2011 at 01:32:56AM -0700, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2011/01/22 01:32:55 > > Modified files: > lib/pixman : configure configure.ac > lib/pixman/pixman: pixman-arm-neon-asm.S pixman-bits-image.c > pixman-combine.c.template pixman-fast-path.h > pixman-general.c pixman-image.c pixman-mmx.c > pixman-radial-gradient.c > > Log message: > Bug-fix upgrade to pixman 0.20.2. No API/ABI change. > tested by shadchin@, ajacoutot@, krw@, ok miod@ > Also tested by ajacoutot@ on sparc. Very important (gcc 2.95) test that I forgot to mention. Sorry. -- Matthieu Herrb
Re: CVS: cvs.openbsd.org: xenocara
On Thu, Nov 11, 2010 at 04:18:56AM -0700, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2010/11/11 04:18:56 > > Modified files: > app/xrefresh : ChangeLog INSTALL Makefile.am Makefile.in >aclocal.m4 configure configure.ac xrefresh.c >xrefresh.man > > Log message: > Update to xrefresh 1.0.7 > That should be Update to xrefresh 1.0.4 -- Matthieu Herrb
Re: CVS: cvs.openbsd.org: xenocara
On Mon, Nov 01, 2010 at 08:58:19AM -0600, Matthieu Herrb wrote:
> CVSROOT: /cvs
> Module name: xenocara
> Changes by: matth...@cvs.openbsd.org2010/11/01 08:58:19
>
> Modified files:
> lib/libXpm/include: Makefile.am Makefile.in
>
> Log message:
> Fix installation when install-sh is not executable.
>
> the nobase_* variables force the use of install-sh, without '${SHELL}'.
> Use a more traditional approach, that uses the normally probed INSTALL
> program. Problem noticed by o...@.
>
And also na...@.
--
Matthieu Herrb
Re: CVS: cvs.openbsd.org: xenocara
On Sun, Oct 03, 2010 at 12:30:04PM -0600, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2010/10/03 12:30:04 > > Modified files: > lib/pixman : COPYING Makefile.bsd-wrapper Makefile.in README >TODO aclocal.m4 config.h.in configure >configure.ac pixman-1.pc.in > lib/pixman/pixman: Makefile.am Makefile.in pixman-access.c > pixman-arm-neon.c pixman-arm-simd.c > pixman-bits-image.c pixman-compiler.h > pixman-conical-gradient.c pixman-cpu.c > pixman-edge-imp.h pixman-edge.c > pixman-fast-path.c pixman-general.c > pixman-image.c pixman-implementation.c > pixman-mmx.c pixman-private.h pixman-region.c > pixman-solid-fill.c pixman-sse2.c > pixman-trap.c pixman-utils.c pixman-vmx.c > pixman.c pixman.h solaris-hwcap.mapfile > lib/pixman/test: Makefile.am Makefile.in alpha-test.c >blitters-test.c clip-in.c clip-test.c >composite-test.c convolution-test.c >fetch-test.c gradient-test.c region-test.c >scaling-test.c screen-test.c trap-test.c >utils.c utils.h window-test.c > Added files: > lib/pixman/pixman: pixman-arm-common.h pixman-arm-neon-asm.S > pixman-arm-neon-asm.h pixman-arm-simd-asm.S > lib/pixman/test: a1-trap-test.c alphamap.c composite.c >gtk-utils.c gtk-utils.h > > Log message: > Update to pixman 0.18.4. > > Tweak build to use libpthread-stubs for TLS emulation instead of forcing > every application using pixman to use -pthread. > > Tested by jasper@ and landry@ on a bulk ports build. Tested by Antoine as well ;-) -- Cheers, Jasper Stay Hungry. Stay Foolish.
Re: CVS: cvs.openbsd.org: xenocara
thank you :) On 2010/07/30 06:28, Okan Demirmen wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: o...@cvs.openbsd.org2010/07/30 06:28:19 > > Modified files: > app/cwm: cwmrc.5 group.c > > Log message: > revert -r1.45 of group.c (log was: fix window name and class to match > cwmrc(5)). instead, fix cwmrc(5) to match the old behavior which also > happens to match the example config, of which many have based their > configs; this also nicely matches the output of xprop(1). > > clean-up of variable names as a separate commit. > > suggested by sthen (and something we should have done initially). > > discussed with and ok oga@
Re: CVS: cvs.openbsd.org: xenocara
personally I think that it would make more sense to adjust the description in the manual to match previous behaviour, rather than change both the code and the example, but if you think this way is better, please could you add a note to faq/current.html so people know they need to adjust their configuration. On 2010/06/28 06:29, Okan Demirmen wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: o...@cvs.openbsd.org2010/06/28 06:29:04 > > Modified files: > app/cwm: group.c > > Log message: > fix window name and class to match cwmrc(5); from Holger Mikolon - thanks! > > ok oga@ > On 2010/07/23 09:13, Okan Demirmen wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: o...@cvs.openbsd.org2010/07/23 09:13:00 > > Modified files: > app/cwm: cwmrc.5 > > Log message: > fix backwards example (after r1.45 of group.c); noticed by phessler@ > > ok oga@ phessler@
Re: CVS: cvs.openbsd.org: xenocara
On Mon, Dec 07, 2009 at 02:20:52PM -0700, Okan Demirmen wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: o...@cvs.openbsd.org2009/12/07 14:20:52 > > Modified files: > app/cwm: calmwm.c calmwm.h xutil.c > > Log message: > introduce the beginnings of netwm support, minimally and correctly; > allows java to be happy, but additionally stops others from whinning > about a non-netwm complaint wm. more to come. > > written a few times; this one includes a clever hack from oga@ to > populate _NET_SUPPORTED. just to expand on this: this commit adds literally the absolute minimum required by the netwm spec: it sets the window manager name, and the hint to show applications that a supporting window manager is running and that's about it. Java has already been patched to notice cwm as a non-reparenting window manager (as well as compiz), and as such the hacks with x11/wmname setting the name to LG3D are no longer needed to run java gui applications with cwm. More work on this will be ongoing (one of the reasons cwm was supported was with the promise that it would grow netwm support one day). -0- -- To the best of my recollection, Senator, I can't recall.
Re: CVS: cvs.openbsd.org: xenocara
Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2009/10/19 14:01:30 > > Modified files: > driver/xf86-video-wsfb/src: wsfb_driver.c > > Log message: > pass the real framebuffer depth to xf86SetDepthBpp() instead of letting > it guess. This lets xf86-video-wsfb on TGA framebuffers on alpha > whithout setting weights and fbpp explicitely. > this was ok oga@ -- Matthieu Herrb
Re: CVS: cvs.openbsd.org: xenocara
On 2009/05/14 10:24, Owain Ainsworth wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: o...@cvs.openbsd.org2009/05/14 10:24:04 > > Modified files: > app/cwm: calmwm.h conf.c cwmrc.5 group.c kbfunc.c > > Log message: > Add a new command (currently no default keybindings for it), grouponly[1-9]. > > This works like the group select binding, but hides all other groups. > > So, the people who've been complaining that they don't get "virtual > desktops" in cwm may want to try this out in cwmrc (from memory, untested): > > --- > > #cwmrc > > # add new windows to the current group > set sticky > > # automatically sticky windows. xclock for now. > # to make more windows sticky use group_toggle to unset their group > autogroup 0 xclock > > # make the group selection keys hide other groups, emulate virtual desktops > bind CM-1 grouponly1 > bind CM-2 grouponly2 > bind CM-3 grouponly3 > bind CM-4 grouponly4 > bind CM-5 grouponly5 > bind CM-6 grouponly6 > bind CM-7 grouponly7 > bind CM-8 grouponly8 > bind CM-9 grouponly9 > > --- to move a window to another group (virtual desktop), you can do it like this: focus window ctrl-alt-g (sticky, red border) use one of the grouponly bindings to switch ctrl-alt-g (unsticky, blue border)
Re: CVS: cvs.openbsd.org: xenocara
Matthieu Herrb wrote: CVSROOT:/cvs Module name:xenocara Changes by: [EMAIL PROTECTED] 2008/08/23 07:19:30 xenocara/driver/xf86-input-digitaledge/obj Update of /cvs/xenocara/driver/xf86-input-digitaledge/obj In directory cvs.openbsd.org:/tmp/cvs-serv22732/obj Log Message: Directory /cvs/xenocara/driver/xf86-input-digitaledge/obj added to the repository Oops. fixed. -- Matthieu Herrb
